On Tue, Apr 10, 2012 at 7:11 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
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.
The "early" variant was intended to perform one-time injection of mapped pages that were acquired before c source code is entered so it was not safe to call common mapping routine yet. I was afraid to implement mapping code in assembly.