> > Ok, Greg, you'll kill me for this, but usb_submit_urb needs a further parameter > > describing a data structure with a pointer to a memmpool and ownership > > of that pool. > > Bleah :) > > Are you sure this is needed? I think the host controller drivers can > handle this properly on their own, by always using a mempool in the > first place. I don't want to burden _every_ usb driver with having to > create such a mempool, when it is the host controller that is the one > that really needs it.
Yes, but alternatively ... for the per-request data, I've thought that we could do better than just the urb->hcpriv pointer. URBs are analagous to "struct sk_buff" in the generic networking layer. No header munging, but certainly a wrapper around the buffer that's actually used for I/O. And those always have a "char cb[]" for use by whoever has the skb queued. Rather than constantly allocating and re-allocating urb-private data as each request gets down to the HCD, it'd seem simpler to just preallocate it -- once, inside the URB. "uhci" would seem to want 64 bytes (on 32bit hardware), the other drivers much less. (While usb-ohci currently wants variable length data there, it's not often even half that size.) Faster too. In general, I'd think we would be better off minimizing per-request memory allocations. We can't avoid them with TDs. Roman has advocated preallocation of config/altsetting data (QH/ED data), and I agree that's desirable. We can also get rid of them in the case of per-URB data. In the 2.5 series that'd be my preference for a "real fix" (along with related HCD updates to promote more uniform behavior). - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
