Uri Lublin wrote: > >> Only if old backend api is UNSUPPORTED. > > Hm. Shouldn't the check be done unconditionally - and for all > > devices, ie. in every pass except perhaps HCD? Otherwise I think > > the bug still bites when installing the previous driver after > > unredirecting the device? > > Yes, it may be a problem if an old libusb driver was already installed. > > I was concerned about the device being opened, and existing in-flight > messages.
If a device becomes unavailable (which can happen without this patch too of course) then the backend has to start failing transfers with LIBUSB_ERROR_NO_DEVICE. Is this what currently happens? > So I preferred to "play it safe" and only change if it was UNSUPPORTED > before. I think it should be done in all cases, or the bug (_get_device_list does not reflect current system state) is only partially fixed. Can you do some tests also for the other way around? A simple way to test is that you in your program first ask the clerk to install the libusb driver, then open the device, then ask the clerk to return the old driver, then try to use the device. It would also be intersting to test libusb_open() in this path, ie. ask clerk to install driver, call _get_device_list(), ask clerk to return the old driver, then call libusb_open(). I would very much appreciate seeing the results from such testing, it would be a good way to determine if there are some concerns for fixing this bug. //Peter ------------------------------------------------------------------------------ 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
