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