On Sun, 28 Jun 2009, Daniel Drake wrote: > Alan Stern wrote: > > An easier approach is for libusb to cancel the URBs in reverse order. > > Then any partial data will all be lined up nicely at the start of the > > buffer, where it belongs. Libusb won't have to do any special > > rearranging. > > Good point. > > > Anybody who cancels a transfer before it has completed is then > > obligated to resynchronize with the device. There are lots of ways > > this could be done; which to use will depend on how the device works. > > Regardless, this is the sort of thing which has to be handled at the > > application level -- not by libusb or the kernel. > > That sounds reasonable for user-requested cancellations, and I can see > the holes in my ideas. It's less desirable for cancellations due to > timeouts (which feels like it should be a less dangerous operation) but > I guess we have no other option. Timeouts _are_ user-requested cancellations. After all, the timeout value originally comes from userspace. Having libusb implement the timeout is merely a convenience; the situation would be no different if the user program started its own timer and explicitly cancelled the transfer when the timer expired. > It looks like that usb_bulk_msg() within the kernel also comes with some > of the same caveats e.g. the timeout might be hit after some packets > have been transferred, meaning that the caller then has to deal with a > bit of inconvenience with resynchronization or stowing that partial data > away for later. Like I said before, this is always true -- and for every kind of message, not just bulk messages. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
