Alan Stern wrote:
Daniel:
I've got an idea for improving the way libusb handles short bulk-IN
transfers (under Linux, anyway -- I don't know about Windows or Mac
OS). It would require some changes to usbfs and corresponding changes
to libusb.
usbfs would be changed so that whenever a bulk URB with the
URB_SHORT_NOT_OK flag set ended with a short packet, all the
outstanding URBs queued to the same endpoint would be unlinked
immediately. In addition, an "endpoint blocked" flag would prevent
further URBs from being submitted to that endpoint until it was cleared
by a new USBDEVFS_UNBLOCKEP ioctl.
I like the idea but I think there is a flaw, or maybe I'm not
understanding it right.
Let's say I use libusb to create 2 64kb transfers to the same endpoint.
I submit both. libusb translates that to 8x16kb URBs, however libusb
still maintains a clear distinction of 2 separate transfers.
The device sends 20kb of data.
The first URB completes all 16kb. The second URB completes 4kb. At this
point, your proposal would cancel all the remaining URBs, even those
from the queued 2nd transfer which we would desire to have left in place
for immediately picking up the next batch of incoming data.
I like your other idea on the thread with David, basically that instead
of rejecting >16kb URBs from userspace, you just split them up into
several 16kb kmalloc()ed "kernel URBs" and maintain the grouping of
several kernel-URBs with the single "userspace URB" within usbfs.
Basically moving that type of logic from libusb to the kernel.
Daniel
--
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
