> > > > URB submission has other failure possibilities than lack of memory.
> > > > Those other things have to be checked for regardless.
> > >
> > > Yes, but that is because you allow too many parameters in the URB to be
> > > changed between USB transfers.
> >
> > No; it's because unforeseen events can occur. For example, the device
> > may have been unplugged or suspended.
>
> On FreeBSD it will never happen that you call the equivalent
> of "usb_submit_urb()" after that the device has detached! It must be
> something terribly wrong in the Linux USB stack if the callbacks are alive
> after that you have detached a USB device.
How does that work then ... driver must grab a lock, check
whether the device has disconnected, then submit the request
and drop the lock? Sounds like needless slowdowns.
Because if there's no lock against async disconnect events,
then it's trivial to have the disconnect logic underway on
one CPU while another CPU does real work, submitting an I/O
request.
- Dave
p.s. You mentioned 16 MB/sec bulk transfer rates. Folk often
get over twice that on Linux, and a few years back there
were measurements of around 50 MByte/sec ... limitations
seeming to come from hardware not the driver stack.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
