On 2012.06.18 15:37, Peter Stuge wrote: > Hotplug isn't there yet, and Liam's problem is because the Windows > backend doesn't currently implement what the libusb-1.0 API currently > offers. Without hotplug. This is a bug in the Windows backend.
After 2 similar issues, you still don't get it, so let me try to explain that to you in black and white: 1. Implementing this will require some form of hotplug handling in the Windows backend similar to what we would do for global hotplug handling (i.e. separate event thread and the whole shebang). There's no other way around it. 2. Some form of hotplug implementation is going to be added once we apply the global hotplug patch, which we have more or less available. We have known for the past 2 years that this global hotplug implementation is going to happen. 3. Therefore, since we are *naturally* going to get a hotplug implementation in the Windows backend, which we can subsequently rely on to implement anything that pertains to device removal, it doesn't make a shred of sense to pre-empt this planned effort and go through a limited implementation, especially any such effort may have to be reviewed and altered once we are through with global hotplug. You may also want to consider that there could exist a possibility to factorize some of the removal related features, instead of having each backend implement its own. Wouldn't it make more sense then if, instead of having people doing their own custom backend implementation, they instead invested their time trying to factorize that handling in core? Thus, the API can say whatever it wants with regards to what occurs on device removal, it doesn't make sense for anyone to go out of their way implementing it in a new backend when they know a global hotplug effort is underway. And that is the approach the Windows backend implementation has taken. If you want to call it a bug, then call it a deliberate bug, because, with the API requirement to send a specific error code on device removal, which is something you recently tried to get Uri to to test for you (whereas you could really have spent 30 seconds looking for libusb error codes returned by the Windows backend and easily found out the answer you were looking for), we just said "we'll do that once we have global hotplug". There is such thing as doing things in a specific order to minimise the resource costs, especially when resources are far from being unlimited. Look it up. You may learn a thing or two about project management... >>> You are the first one to report it, but there have not been very many >>> reports of libusb use on Windows at all, so that doesn't mean much. >> >> Liam, I'm afraid you'll find that many people on these lists don't >> agree with these kind of subjective statements from Peter. > > I guess that Liam gets the point; we don't have much data, so we > can't say that this is a known problem. No. The point you have been trying to make, as corroborated from many other posts from yours in libusb-devel and elsewhere, is that the Windows backend is subpar compared to the rest of libusb and also that extremely few people use it. Assuming that you have spent the last 2 years monitoring libusb-devel, I find this quite the disingenuous statement to make, unless of course you can list some evidence to back it up, which I have diligently been asking for each time you tried to present your very subjective appraisal as an undeniable fact. 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
