Date: Mon, 05 Mar 2001 18:29:27 -0800
From: David Brownell <david-b@pacbell.net>
Subject: Re: [linux-usb-devel] Re: SLAB vs. pci_alloc_xxx in usb-uhci patch
To: linux-usb-devel@lists.sourceforge.net, Russell King <rmk@arm.linux.org.uk>
Cc: Manfred Spraul <manfred@colorfullife.com>, zaitcev@redhat.com,
        linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Message-id: <026b01c0a5e5$4513e740$6800000a@brownell.org>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
In-Reply-To: <E14a6uW-0008Gd-00@the-village.bc.nu>
Sender: linux-kernel-owner@vger.kernel.org

> > At the time, I didn't feel like creating a custom sub-allocator just
> > for USB, ...
> >
> > I'd be good to get it done "properly" at some point though.
> 
> Something like
> 
> struct pci_pool *pci_alloc_consistent_pool(int objectsize, int align)

    struct pci_pool *
    pci_create_consistent_pool (struct pci_dev *dev, int size, int align)

and similar for freeing the pool ... pci_alloc_consistent() needs the device,
presumably since some devices may need to dma into specific memory.
I'd probably want at least "flags" from kmem_cache_create().


> pci_alloc_pool_consistent(pool,..
> pci_free_pool_consistent(pool,..

These should have signatures just like pci_alloc_consistent() and
pci_free_consistent() except they take the pci_pool, not a pci_dev.
Oh, and likely GFP_ flags to control blocking.


> Where the pool allocator does page grabbing and chaining

Given an agreement on API, I suspect Johannes' patch could get
quickly generalized.  Then debugging support (like in slab.c) could
be added later.

- Dave


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