On Wed, 6 Jun 2012, Hans de Goede wrote: > > usbfs can then: > > > > a) verify each iovec entry is not too long > > b) verify the total length of the iovec isn't too big > > c) translate each iovec entry into one sglist vector > > d) submit one URB with a populated sglist to the USB core In fact, the kernel doesn't need to support iovecs for usbfs. (We can, but we don't need to.) Libusb doesn't support them, after all. All we really need to do is teach usbfs to copy large data buffers from userspace to the kernel in suitably small chunks, creating an sglist to keep track of the chunks. Then libusb would need only to _avoid_ breaking big transfers up into pieces. ... > Before writing up a proposal on this, let me start with some questions: > > 1) Do we want to support bulk streams in the synchronous API, iow with the > USBDEVFS_BULK ioctl, or just with the async API, iow with USBDEVFS_SUBMITURB > and friends? (as well as with the new iovec capable async API There's no way to support bulk streams with the USBDEVFS_BULK ioctl. A new ioctl would be needed. > I personally think it is fine to only support them with the async API. I can't think of any reason for doing synchronous I/O with bulk streams. The whole point of streams is to allow multiple transfers to proceed concurrently. ... > Thats all for now. One last remark: We must not forget to document that the > URB_SHORT_NOT_OK flag does not always halt the ep on a short urb! Yes, the documentation must be updated to note that xHCI is an exception. 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
