Hi, On 05/03/2012 01:13 PM, Pete Batard wrote: > On 2012.05.03 11:55, Hans de Goede wrote: >> IMHO the current libusbx-1.0.x behavior on windows is a bug and needs >> to be fixed, > > IMHO, not having hotplug in libusb(x) is a major bug, rather than a just > another very desirable feature, that should be fixed ASAP. In terms of > priority, besides critical bugs that pop out and need an immediate fix, > that would be on the top of my list.
I agree it is an important missing feature, and that it is something which should have been added a long time ago. >> so this is not about needlessly adding new functionality >> duplicating effort, it is about fixing a bug. > > Yes, I agree. Except I see it part of a larger bug that also need to be > fixed. hehe >> My problem with aiming for a hotplug solution here, is that a stable >> release of such a solution (ie of libusbx-2.0) will be a long time away. > > 2.0 is a long time away, but a usable -devel may not. The plan is of > course to have a -devel that, while experimental, is as stable as > possible and that people can use in their apps. The problem is that we want to have it integrated into Fedora and also RHEL, so as stable as possible is not necessarily good enough. I know stable releases can and will have bugs too, but going with a devel release will be a hard thing to sell. >> Where as a fix for just this issue can be done much quicker and added >> to libusb-1.0.12. > > As I said I currently sit on the fence with regards to this patch. > > Obviously, I would very much prefer having you guys use hotplug, as it > would help us validate our implementation, which would benefit others. > Also, considering that you will have to remove the patch and switch to a > hotplug solution sooner or later, it might be worth ensuring you still > have your requirements filled when that happens. I've just discussed this with Uri and Arnon and we definitely want to drop our platform specific hacks for this and switch to libusbx hotplug support in the near future. So as soon as there is something testable you can count on us to try and convert spice to that and run various tests with it. And I've already learned the hardway that Spice's redir code is one of the more stressing users of libusb (as it needs to work with any random device), so you can count on it getting some good testing when we switch over :) > But if not having something quick is a major issue, I don't have a major > problem integrating it (though I haven't really reviewed it yet). > >> I understand, the problem is that we need a solution for this in a relative >> short amount of time > > What are your constraints there? We need a solution in say max a month from now. Note that even if you were to manage to do a stable release with hotplug support in that timeframe, we won't have the time to convert and revalidate all our code in that timeframe. So although such a release would also fix our issue with re-numeration, we won't be using the new functionality just yet. As said above we will switch to it asap, depending on the libusbx schedule I'm thinking / hoping of having spice use libusbx-hotplug for Fedora 18, so that is slightly more then 6 months from now for the official release. >> Hmm, reading further below I think I may have misunderstood things, if the >> plan is to add hotplug to libusbx-1.0.x, and do a release of that in >> a reasonable timeframe I can understand your POV even more then before. > > Actually, that wasn't really my plan, but if there's a vote to try for > hp in 1.0, I'm really all for it, as the proposal was designed for 1.0 > anyway. I'd have no problem moving hp before libusb0/libusbk support and > other things. I for one would really love to see hp in 1.0, libusb0/libusbk support is also quite important to us though, and also something we would really like to see in 1.0 >> Still we have a need to get a fix out soonish as we want to make available >> a windows spice client with (limited, winusb only) usbredir support >> soon-ish. > > soonish = ? As said max a month from now. >> We can carry a patch to our windows libusbx copy for that if it is >> temporary, still a review would be appreciated in case we're breaking >> things >> without realizing it. > > We might as well have it in mainline if you guys use it, as it could > benefit others. I'll see what I can do for review... Thanks! Regards, Hans ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
