Re: [patch 3/8] mm: merge nopfn into fault

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2007-05-23 at 19:04 -0700, Linus Torvalds wrote:
> 
> If you want to install the PFN in the low-level driver, just
> 
>  - pass the whole "struct vm_fault" to the PFN-installing thing (so that 
>    the driver at least doesn't have to muck with the address)

Fair but in the case of spufs, I -do- have to much with the address in
the driver/fs since it's the driver that knows it wants to use 64K page
mappings, and thus need to insert the PTE with the special 64K flag in
the first of the 16 entries of that 64K region -and- align the address
down before passing it to vm_insert_pfn().

There no knowledge of that arch magic in the generic vm_insert_pfn() and
I don't think there should be. It's all understanding between the arch
specific spufs driver and the arch low level page table management.

I know I'm sort of a special case here though, but I think it might make
sense to have in the future the DRM do similar special things to use
larger HW page sizes to map things like framebuffers or large in-VRAM or
in-AGP objects, possibly using an arch helper that does that appropriate
address & pgprot flag munging, but in the end, the actual PTE insertion
is still the generic one and that should work just fine.

Anyway, I don't see any big hurry to change ->nopfn() and it's
associated NOPFN_REFAULT special return code and vm_insert_pfn() helper
from what they are right now. They work for the few special case that
need them just fine and can be kept separate from whatever other work
Nick is doing.

Cheers,
Ben.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>