Hi, On 05/03/2012 12:40 PM, Pete Batard wrote: > On 2012.05.03 08:55, Hans de Goede wrote: >> Well you've hotplug and hotplug, what is expected by spice is that after >> it detects a hotplug itself (through platform dependent code) that it can >> then do a new libusb_get_device_list() call and the new device will be >> there. > > Which will happen when we have hotplug in libusb, as driver installation > will generate a system hotplug event which will ensure that > libusb_get_device_list() returns an up to date / real-time view of the > devices available to libusb => this patch shouldn't be needed.
I understand that hotplug will give us what we want, and we would love to switch to libusb hotplug rather then having our own platform dependent code to detect device addition / removal. >> So we're not asking for true hotplug, just that when we ask to >> re-enumerate devices we get an updated device list. > > I understand that. This doesn't detract from the fact that your > requirement is meant to be handled by hotplug, as the installation of a > driver or the plugging in of a new device are pretty much the same thing > on Windows, as far as libusbx is concerned. Your solution would > duplicate something that we're going to solve (in a different manner) > when hotplug is in, and in general, duplicating solutions, or > integrating a solution that we know will be removed later on, seems kind > of a wasted effort. IMHO the current libusbx-1.0.x behavior on windows is a bug and needs to be fixed, so this is not about needlessly adding new functionality duplicating effort, it is about fixing a bug. As said before re-enumeration though calling libusb_get_device_list() does work / include new devices on other platforms, and the docs say: "Returns a list of USB devices currently attached to the system. " Notice the *currently*, as in at the moment of the call... >> This is how things >> currently work on other platforms. > > Yes. And if you want, you should be able to get the same if you use the > hp branch from -pbatard, without the need to apply your patch (though > the branch probably needs some update and I'm trying to find the time to > update it...). So I could state that this is also how things work on > Windows. The only problem is that while the solution that should avoid > your issue has been available for about 18 months now, it still hasn't > been reviewed and integrated, and this is detrimental for all libusbx > users. So that's what I would like us to work towards. I'd rather see > time spent on a hotplug solution that solves your and other people's > problems& requirements, than a patch that just solves your problem. > This will of course take longer, but it should also be a lot more > beneficial for everyone. 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. Where as a fix for just this issue can be done much quicker and added to libusb-1.0.12. > >>> Given the choice, I'd rather work on kickstarting the libusbx 2.0 branch >>> and apply the hp patches I have in -pbatard, but it may take a while... I understand, the problem is that we need a solution for this in a relative short amount of time and we're willing to do the work for that, so can you please review the proposed patch for fixing the enumeration behavior of the 1.0.x branch. And if the patch sucks we'll try to address your concerns. 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. 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. 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. >> TBH I'm not convinced that adding hotplug requires an ABI / API break, > > The hp branch begs to differ. We do have an hp proposal that doesn't > require an API/ABI break and it was very much designed that way. We will > of course add to the API, but so far I don't remember having identified > anything that requires an API break. Oh, good! > > Now, we also do have a separate issue with cross platform event > handling, that we also need to solve, and that is likely to require an > API break. But that's a library-wide issue. Since hotplug would benefit > from cross-platform event-handling, maybe that's the reason you consider > that hp will require an API break, but the truth is that, hp or no hp, > we'll need upgrade our event handling regardless, so it's not directly > related. > >> and if possible I would like to avoid that. > > Same here. How about we look into a proposal then and see whether we > think we can make it work without breaking the API/ABI? Definitely. You say you've a branch for this, TBH I would like to start with looking at the API and then dive into the code from there, can you extract or summarize the API (for all I care you run doxygen, drop the output somewhere and point me there), so that I can take a look? >> I'm fine with having a >> devel and stable branch, but I would like to avoid declaring the devel >> branch a do whatever you want to the API/ABI area. > > Commits to this branch will be subject to the same review process as > mainline, and it is meant to provide an upgrade path from 1.0, so I > don't exactly see how it's meant to be seen as a "do whatever you want" > branch. > >> What I propose is that whenever we are thinking about a feature which >> may need API breakage, we first design the API for that feature, without >> taking compatibility in mind, so we assume API breakage is ok for the >> initial design. And then we do an iteration where we try to see if we >> can make it fit with the current API, if we can -> hurrah. If we cannot >> then we've a good reason to start an API incompat branch. > > I'm fine with that. > >> This is also the procedure I would like to follow with hotplug. > > The current hp proposal doesn't break the API. As far as I could see, > Nokia (who are the originators of it) very much followed your proposal > of not unnecessarily breaking the API. Again: Good, most of my previous mail was then from me misunderstanding things, I was under the impression that people were itching to have a break of API/ABI compatibility and be able to do at least some API changes I'm glad to hear that that is not the case and sorry for the noise. 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
