[OpenBIOS] [PATCH 1/8] Rename ofmem_arch_early_map_pages() to ofmem_arch_map_pages().
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