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?
ATB,
Mark.