Re: can device drivers return non-ram via vm_ops->nopage?

[Russell King]

On Sun, Mar 21, 2004 at 01:53:41PM -0800, Linus Torvalds wrote:
> So I really put my veto on "nopage()" returning a PFN. That's just wrong, 
> wrong, wrong. It returns a "struct page" pointer, and it has lots of 
> reasons for that.

Ok then.  We leave nopage() as is, and define that for returning RAM
backed pages.

We also have a fault() handler which is used for faulting in driver
mappings, which returns a PFN suitable for set_pte().  The fault()
would be separate from do_no_page() in much the same way as
do_anonymous_page() is separate, and it knows that PFNs returned
from this have nothing to do with struct pages.  All it does is
set the relevant PTE entry in the page tables to create the mapping.

I don't think remap_area_pages() solves the problem - think about
the DMA ring buffer returned by dma_alloc_coherent().  This returns
an architectually defined virtual address and a DMA address.

Neither of these two addresses can be converted today to a struct
page or a PFN.  Sure, we can invent some architecture defined
interface to get hold of this information, but take a moment to
consider all the cases where this type of activity goes on.

What about the case where the buffer is scatter-gather in nature,
just like we're so fond of telling driver writers who want to grab
(eg) 1MB of contiguous kernel memory for video buffers and the like?
Do we really want to tell driver writers to walk over 1MB of pages,
page by page, inserting them into the processes page tables via
remap_area_pages()?

Or does the ->fault() method make sense in all these cases?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/