On 2012.05.14 19:30, Peter Stuge wrote: >> .. hotplug .. > > The bug is that the Windows backend requires a libusb_device * to be > unref:ed before libusb_get_device_list() reports system changes, > while other backends do not have this limitation and it is documented > that libusb_get_device_list() does not have this limitation.
You still fail to understand that, on a project, it is counter-productive to spend time pre-empting the implementation of part of a feature that is meant to be implemented in full later on, especially if that pre-emption means adding and then later removing a patch (adding a patch is no big deal - removing one when addons may have affected the same code section can be a lot more tricky). That other backends have decided to pre-empt something that rightfully belongs to hotplug, by implementing part of the device refresh that belongs there, is their choice (or probably the logical conclusion of NOT expecting hotplug anytime soon). Still, the smart approach, when you are strapped for time, and you know there will be an effort later on that will _duplicate_ whatever you want to pre-empt here and therefore bring the feature, is to simply wait for that effort to occur. This is what I've been advocating, as it seems like the most sensible approach right now, because it avoids _wasting_ time adding and then removing code. >> you're asking for hotplug before we implement hotplug. > > No, I'm confirming that the non-hotplug-supporting API has a bug in > the Windows backend. Except, you hadn't confirmed anything at this point, as the only actual verifiable data you got were the results of MY test, which seemed to disprove that there existed an actual problem for regular users. So how you got to "confirming", despite evidence that seemed to disprove your point, is a bit of a mystery, especially as you didn't point anything with regards to my testing that would have indicated that my results were expected to be irrelevant (which you should have been able to do if your conclusion was indeed "confirmed"). Uri had not provided anything further at this stage to indicate that this may affect a non specific hotplug usage of libusbx (still need to test). And you did state previously that "If replacing the driver does not lead to a new libusb_device * for the device then I think it is a bug", which is a fair statement (since you are entitled to your opinion), but quite a far cry from this later statement where you now seem to be in a position to "confirm" a sure-thing bug (still seemingly without the annoying burden of having to provide data to back up your claim). Excuse me then if still see your "confirmation" statement here as not entirely receivable due to lack of data to back it up. Now of course, if you're lucky, data that seems to go your way may still be provided afterwards, but, if we acknowledge this later data, it kind of goes against the face of causality, and if we don't, then the "confirmation" of your conclusion here leaves a lot to be desired, on a scientific level... 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
