Hi Sarah, Sarah Sharp wrote: > > 2) Change usbdevfs to use an sg like interface for the BULK_CONTINUATION > > flag, which also means changing the userspace API since userspace now > > also needs a way to signal that the first urb is part of a multi urb > > transfer > > 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. Do you know since which kernel version this is possible? > 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 Lots of verification. Will the error paths for those verifications be any different from what is being done today? Put another way: Given a 4Mbyte transfer with the way libusb works now, and putting that in an iovec instead, how would the ioctl() fallout differ? If there would be an error on submit when using an iovec, does that error instead happen on reap when submitting lots of individual URBs? > the job is half done, although arguably the userspace half is the > harder half, since it requires getting libusb developers on board. I'm the libusb maintainer since a little less than two years. I've been involved in the project for about eight, and was offered to take over as maintainer already in 2007, but declined at that time. I've worked some 1000-1500 unpaid hours on a long list of action items since the previous libusb release 1.0.8, including lots of bugs, the odd new feature, project infrastructure, and last but not least on getting contributions for Windows support in libusb included, which finally lead to the 1.0.9 release in late April. There were a few other active contributors in the libusb community during this time, one of which is Hans, he got involved when we met at FOSDEM in 2010 and he told me about his work on USB redirection for SPICE, and about the things he needed from libusb in terms of new functionality. (He's also the package maintainer in Fedora.) A fork of libusb has been announced, called libusbx, with the quite outspoken purpose to replace the libusb project, and shoehorn me away as maintainer, because I am very damaging to the project. (I want commits to be reviewed before inclusion in libusb.git, and when noone else does review I can't always do it timely enough to keep everyone happy. My bigger mistake was to not manage the quite problematic Windows development effort better, which made the 1.0.9 release to take nearly two years to finish.) The fork effort is spearheaded by the developer of the libusb Windows support, who doesn't get along with me, as well as by Hans along with at least two colleagues of his at Red Hat as the other driving development force. The code difference is quite minimal between the two repositories, since libusbx.git was forked from libusb.git very recently. To get back on topic, I think that libusb giving iovecs to the kernel is absolutely the right thing, and as a bonus it will remove some complexity from libusb, which is always a good thing! :) I'm on board since a long time already. Between myself, Hans, and Alan (who has also contributed to libusb) I don't think moving to use iovec is a big problem. The only thing that is important for the change is that libusb shouldn't suddenly start behaving very differently as a consequence, but I'm not really worried. I hope you can the error case questions can be answered though, that's where the hairy details are. Thanks //Peter -- 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
