> > 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). > > Can we in this way totally avoid allocating memory in the HCDs ?
There's a principle called "modularity" that argues against pushing knowledge to places it doesn't belong ... like details of QH/ED and TD memory allocations being handled outside the HCDs that need those data structures! :) The only allocations I suggested getting rid of is for "urb->hcpriv", by a strategy like skb->cb in the networking subsystem. Safe enough, I could imagine that even going into 2.4 kernels. Establishing QH/ED state at a better time/place would be more work, but I think it'd be worthwhile in the 2.5 kernels ... it'd certainly make it easier to do some things in the HCDs, and to abstract some of the scheduling so there are fewer HCD-specific behaviors. And by moving those allocations out of the per-request path, that's one more category of potential swap problem that's eliminated. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
