On Wed, Jun 06, 2012 at 10:56:12AM -0400, Alan Stern wrote: > 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. Point taken! That would be far less work. I think we would still need the new capability ioctl so that libusb could know that it doesn't need to break up large transfers. Or could it just submit large transfers with one buffer, and then just fall back to breaking it up if the submission failed? Hmm, would it be possible to change usbfs to pin_user_pages for each iovec entry instead of copying it into a new buffer. Then we would get zero copy for free. (Yes, I know I'm crazy to tack zero-copy onto the list of potential features, but it would be pretty awesome.) > ... > > > 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. Why don't you think we could use the USBDEVFS_BULK ioctl? Because we need to know whether to use the stream ID? Or for some other reason? I'm not opposed to a new ioctl, I just want to understand your reasoning. > ... > > > 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. Is updating the documentation enough? Or should usbfs fail submission of URBs with the BULK_CONTINUATION flag set when it detects it's under an xHCI host? Sarah Sharp -- 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
