[OpenBIOS] [PATCH 1/8] Rename ofmem_arch_early_map_pages() to ofmem_arch_map_pages().

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Tue Apr 10 17:11:08 CEST 2012

On 10/04/12 13:20, Andreas Färber wrote:

> Hi Mark,
> Am 06.04.2012 21:48, schrieb Mark Cave-Ayland:
>> This OFMEM call does actually map the page for the architectures that
>> require it, so let's change its name so that we now have a symmetrical
>> ofmem_arch_map_pages() and ofmem_arch_unmap_pages() API.
> I don't really mind either way, assuming you've compile-tested it.

Sure, I've tested PPC with my patches applied and it seems to work - I 
notice though that PPC looks as if it already allocates it's Forth 
machine memory outside of the image - please correct me if I'm wrong? 
I'm not too familiar with the way the PPC MMU works with hash tables.

> I would've assumed though and "early" indicates at which times in the
> code this function may be used?

Well, it's more interesting than that. For SPARC, when you map the 
memory it is first added to the translation_t linked list. The TLB miss 
handlers simply iterate over this list in order to find the mapping 
before continuing. Therefore when creating a mapping, since the 
translation_t list already contains the entry created by 
ofmem_map_page_range(), all the ofmem_arch_map_pages() function has to 
do is update any existing TLB entries.

Now I'm quite tempted to rename ofmem_map_page_range() to 
map_page_range() or similar and remove it from the public OFMEM API 
(only SPARC64 seems to use it) to make things a little clearer as to the 
difference between the two functions and also create the symmetry with 
unmap_page_range() in ofmem_common.c - what do you think?



More information about the OpenBIOS mailing list