On Thu, 25 Jun 2009, Daniel Drake wrote: > 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. You're right. > 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. This could work. Let me think about it... 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
