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. > 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. > 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. >> 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... > > 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. 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? > 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. Regards, /Pete ------------------------------------------------------------------------------ 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
