On Mon, 1 Nov 1999, Russell King wrote:
> > Thats the reason why we should implement PageSkip().
>
> And the other thing I spot here is that I believe that __pa() is NOT a
> short name for virt_to_phys, but __pa() is supposed to return the offset
> into physical memory, not the address OF physical memory (which virt_to_phys
> does).
In mm/memory.c:remap_pte_range() __va() gets a real physical address as
argument and not an offset. Here you have to take care that __va() returns
either a valid virtual kernel address for MAP_NR() or it has to return an
(arbitrary) invalid virtual address, so that following test against
max_mapnr is true. If you don't do this, you have problems mapping video
or kernel memory into user space, so that either nothing is mapped at all
or the wrong pages are freed, when the user mapping is released.
Only MAP_NR() has to return an offset into mem_map, but __va()/__pa()
could be used on m68k to provide faster variants of phys_to_virt() and
virt_to_phys() if possible, whereof the mm system could benefit from this.
> I've already grappled with this on the ARM since we have a similar
> problem - some architectures have contiguous memory starting at either
> 0x00000000 or 0x10000000 (physical) or even worse memory which can be
> in up to 4 banks spread out across 256MB. No changes to the generic
> code were necessary.
So far that wasn't really a problem since the mm system only worked with
virtual address and the translation between physical and virtual mapping
was completly architecture specific. Now bootmem.c makes an exception to
that, but adding an dynamic start would reduce the problem, since it's
only a simple bitfield and freed after booting.
bye, Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/