David Brownell wrote: > > In the interest of de-complicating the API and code, > I wonder how folk would react to removing the flag > that enables bulk queuing ... doing it as needed but > without needing an explicit request. ...
Sounds good. But there is more: Right now there is one queue for each endpoint. That means - if you submit a new URB the low level driver has to search for other submitted URBs for the same endpoint; this can be done either in a complex and efficient or a simple and slow way... not good. - there is no possibility for a device driver to build a single queue for different endpoints. Example: device sends data on endpoint 1, host acknowledges on endpoint 2, device sends data on endpoint 1, and so on. At the moment it's stop and go with no way to schedule in advance. So, define something like an usb_queue_t (an URB fifo, with URBs linked by a link field in struct urb) as a new datatype in the usb core, opaque to the device driver, accessible by the low level driver, and make it a parameter to usb_submit_urb. Stephan _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
