From: David Brownell <david-b@pacbell.net>
Date: Wed, 12 Jun 2002 00:06:39 -0700
David S. Miller wrote:
> 0 is a valid PCI dma address on many platforms. This is part
> of the problem.
OK, so a new call syntax would be desirable. Or reserving page zero
even on such platforms.
Or, better yet, define a PCI_BAD_ADDR per-arch.
> Huh? The whole idea is that it is memory for PCI dma, it has to be
> PCI in nature. If you want a kmalloc'ish thing, simple use
> pci_alloc_consistent and carve up the pages you get internally.
And the reason that logic doesn't lead us to rip kmalloc() out of
the kernel (in favor of the page allocator) is ... what? Every driver
shouldn't _need_ to write yet another malloc() clone, that's all I'm
saying; that'd be a waste.
That is why we have the PCI pool thing, it's PCI alloc consistent +
SLAB carving.
Certainly hanging some sort of memory allocator object off struct device
should be pretty cheap. At least for USB, all devices on the same bus
could share the same allocator. Not that I know PCI that well, but I
suspect that could be true there too ... more sharing, less internal
fragmentation, and more efficient use of various resources.
These instances we are talking about want to allocate multiple
instance of the same object (thus the same size). They are not
allocating things like variable length strings and whatnot.
That is why I keep suggesting PCI pools, it's the perfect kind of
setup (and the easiest to implement). A generic kmalloc() out of
pages is more to implement, certainly.
If you want to hide this behind a usb_dma_pool_create,
usb_dma_pool_alloc etc. kind of interface that calls back into the
host controller layer to get the pci_dev etc., that's fine.
Now enough talking and someone implement this, talk is cheap.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:25 EST