From: Alan S. <st...@ro...> - 2009-08-19 16:31:43
|
On Fri, 31 Jul 2009, Alan Stern wrote: > Daniel and David: > > This kernel patch implements the plan we discussed for handling short > bulk transfers. It adds a new URB flag: USBDEVFS_URB_XFER_START. > Here's how it works: > > When libusb breaks a bulk-IN transfer up into multiple URBs, it should > set > > USBDEVFS_URB_SHORT_NOT_OK | USBDEVFS_URB_XFER_START > > in the flags for the first URB, and > > USBDEVFS_URB_SHORT_NOT_OK > > for all the following ones. If any of these URBs completes with an > error before libusb has finished submitting all of them, it should stop > the submissions (they'll fail anyway with an EREMOTEIO error; perhaps > a different code would be better). It probably already does this. > > The kernel changes are transparent for URBs that don't have > USBDEVFS_URB_SHORT_NOT_OK set; they'll just sail on through as before. > Hence versions of libusb that aren't updated should continue to work > with no ill effects. > > But for bulk-IN URBs that do have this flag bit set, any fault other > than an unlink will cause the kernel to immediately cancel all the > following URBs for the same endpoint and refuse to accept any new ones. > This state of affairs will persist until an URB that also has > USBDEVFS_URB_XFER_START is encountered, at which point the behavior > reverts to normal. Such an URB would of course mark the beginning of a > new transfer. > > The patch behaves correctly in simple tests on my system. We should be > possible to get it incorporated into version 2.6.32 of the kernel if > you want. Do you have a good way to try it out? Daniel, I haven't heard back from you about this. Do you think it should be added? And what about David's suggestion for adding a USBDEVFS_URB_CANCEL_ON_ERROR flag instead of USBDEVFS_URB_XFER_START? Alan Stern |