kmalloc is implemented in terms of the slab cache, so we effectively already have this.
I don't think creating our own slab cache will buy us very much. JE On Tue, Dec 11, 2001, Matthew Dharm <[EMAIL PROTECTED]> wrote: > Hrm... since a devrequest structure is needed by anyone who wants to do a > control request, and most of the uses seem to be "allocate, use, destroy", > would a slab cache be useful here? I mean a USB-wide one, not a > per-sub-driver one. > > Matt > > On Tue, Dec 11, 2001 at 03:14:22PM -0500, Johannes Erdfelt wrote: > > On Tue, Dec 11, 2001, David Brownell <[EMAIL PROTECTED]> wrote: > > > > All of the USB host controller drivers are PCI devices. > > > > > > Various folk have said they want to integrate patches > > > for some of those non-PCI OHCIs in the 2.5 tree, so I'd > > > expect that to change. > > > > > > Re the original patch, I think that's a case of "better safe > > > than sorry". Not DMAing to/from the stack is a general > > > rule for the whole kernel, not just USB. > > > > I seem to recall Alan Cox mentioning that it's not guaranteed to be safe > > in any kernel since some architectures will move to a non DMA capable > > stack. > > > > IMHO, since the only safe thing to do across all architectures is to > > kmalloc the devrequest structure, anything other than that is essentially > > micro optimization that's not worth it. > > > > JE > > > > > > _______________________________________________ > > [EMAIL PROTECTED] > > To unsubscribe, use the last form field at: > > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > > -- > Matthew Dharm Home: [EMAIL PROTECTED] > Maintainer, Linux USB Mass Storage Driver > > Oh BAY-bee. > -- Dust Puppy to Greg > User Friendly, 12/13/1997 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
