I noticed that usb-skeleton.c still has a TODO entry referring to a race
involving urb->status, so I took a closer look. Fixing that race will be
easy, and I will be happy to submit a patch for it. But there are two
other problems, partially related. Is it worthwhile to try to address
them all? Is there no point, seeing as how usb-skeleton.c is just
intended as a programming guide? But on the other hand, shouldn't a guide
be _especially_ careful to do everything right?
Here are the problems.
(1) Device writes use a normal, asynchronous usb_submit_urb()
call to do their work. They return without waiting to see if the bulk
data transfer succeeded. Thus any problems during data transmission will
not be reflected back to the user.
(2) The release() routine unlinks an ongoing write in progress.
This means that the last buffer of data written to the device before it is
closed will quite likely never be delivered. Owing to problem (1), the
user will not be aware of this.
Changing the write() routine to use usb_bulk_msg() would fix all these
problems, but this would defeat the purpose of showing people how to use
usb_submit_urb(), usb_unlink_urb(), and completion handlers. What do
you think is the right thing to do here?
(Incidentally, usb-skeleton.c is a good example of a driver where the
disconnect() routine can exit with urbs still in flight.)
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
