On Wed, Jun 6, 2012 at 3:32 AM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > On Tue, Jun 05, 2012 at 01:12:44PM -0400, Alan Stern wrote: >> On Tue, 5 Jun 2012, Sarah Sharp wrote: >> >> > Or just change libusb to not break up large transfers, and get rid of >> > the BULK_CONTINUATION flag all together. libusb should submit >> > the whole transfer to usbfs with an iovec. 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 >> >> I think this would work. But it wouldn't help people trying to use >> libusb with xHCI on older kernels. > > No, it wouldn't help them. At some point though, users just need to > upgrade their kernels. And if enterprise distro kernels decide they > care about those particular users, they can pick up the patches. I > think Hans was already volunteering to try and push the necessary kernel > changes for RHEL. I think this is fair. xHCI on older kernels may not work well anyway. BTW, It is similar under Windows that xHCI may or may not work well on Windows XP/Vista/7 where there is no official Microsoft driver for them. On the other hand, libusb/libusbx should probably need to put a note that it may not work with USB 3.0 ports prior to kernel 3.x (where 3.x is the first kernel to solve this issue). > It might be worth it to ensure that the old usbfs calls without iovecs > can co-exist with the new calls, so that we don't break older API. That > will make it easier to convince distro kernels to pick up the usbfs > changes. -- Xiaofan -- 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
