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

Reply via email to