> Please don't limit the API design to PCI ;)> > When I say "PCI pools" think "struct device pools" because that> will what it will be in the end.> > That is Linus's long range plan, everything you see as pci_*> will become dev_*.

I think the guts of it could happen in the 2.5 series soonishthough, so it'd only be "long range" in that quaint Wall Streetsense of "finishes sometime after next quarter". :)

Just to put some flesh on the discussion ... here's the roughshape of what I was thinking, as more wood for the fire:

- Associated with a "struct device" would be some kind of memory allocator/mapper object that would expose every (?) primitive in DMA-mapping.txt, but not PCI-specific. That would basically be a vtable, using the device for state.

Example: all USB devices connected to a given bus would normally delegate to the PCI device underlying that bus. (Except for non-PCI host controllers, of course!)

And the PCI versions of those methods have rather obvious implementations ... :)

- There'd be dev_*() routines that in many cases just call directly to those methods, or failed cleanly if the whatsit wasn't set up ("used the default allocator"), or omitted key methods. Many could be inlinable functions:

- Some of the other driver APIs would want to change to leverage these primitives. They might want to provide wrappers to make the dev_*() calls given the subsystem device API.

Again using USB for an, one _possible_ change would be to make urb->transfer_buffer be a dma_addr_t ... where today it's a void*. (Discussions of such details belong on the linux-usb-devel list, for the most part.) That'd be a pretty major change to the USB API, since it'd force device drivers to manage DMA mappings. While usb-storage might benefit from sglist support, other drivers might not see much of a win.