On Wed, 6 Jun 2012, Sarah Sharp wrote: > > 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.) Now you're talking about adding mmap to usbfs. At least, that's what you were planning with usbfs2, right? > > > 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. Because there's no place in the existing ioctl and data structure to pass the stream ID. Even the idea of reusing the number_of_packets field has limitations, because async bulk submissions aren't required to set that field to 0. Of course, if the application has to enable streams before it can use them then that won't be any issue -- we can assume that once streams are enabled on an endpoint then the number_of_packets field will always be set correctly. > > > 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? How can usbfs tell whether the host controller is xHCI? Remember, the connection will probably be running at high speed, not SuperSpeed. 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
