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

[Jeff Garzik]

I wonder if we could jump back a step...

Years ago, I wanted to avoid remap_page_range() when I was writing 
via82cxxx_audio.c, and so Linus suggested the ->nopage approach (which I 
liked, and which is still present today in the sound/oss dir).

AFAICS device drivers have three needs that keep getting reinvented over 
and over again, WRT mmap(2):
1) letting userspace directly address a region allocated by the kernel 
DMA APIs
2) ditto, for MMIO (ioremap)
3) ditto, for PIO (inl/outl)

Alas, #3 must be faked on x86[-64], but this is done anyway for e.g. 
mmap'd PCI config access.  Many platforms implement in[bwl] essentially 
as read[bwl], so for them mmap'd PIO is easy.

#1-3 above are really what device drivers want to do.  My 
suggestion/request to the VM wizards would be to directly provide mmap 
helpers for dma/mmio/pio, that Does The Right Thing.  And require their 
use in every driver.  Don't give driver writers the opportunity to think 
about this stuff and/or screw it up.

If there are special DMA requirements of a particular bus or platform, 
hide that in there.  If some methods of DMA or MMIO or PIO do not lend 
themselves to directly mapping to a struct page, the MM guys may dicker 
about the interface, but the device driver guys just want #1-3 and don't 
really care :)  Either it's directly addressible [via some page table 
magic] from userland, or it isn't.

So please forgive the tangent, but this thread is IMO talking more about 
implementation than the real problem :)  pci_dma_mmap() helper or 
something like it should be the only thing the driver should care about. 
 I'm tired of the same platform bugs and issues, in mmap handlers, 
reappearing over and over again...  Tired of platform-specific ifdefs in 
mmap-capable drivers, too.

	Jeff



-
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/