On 05/10/2012 02:28 PM, Pete Batard wrote:
> On 2012.05.01 16:52, Uri Lublin wrote:
>> Only if old backend api is UNSUPPORTED.
>>
>> This happens when a libusb driver (e.g. WinUSB) is installed
>> after a device has been setup/discovered (with get_device_list).
>
> I'm currently testing this, so that I can review the patch, but I'm
> not seeing much of an issue with the original code.
>
> I'm using a modified xusb with the following patch:
> -------------------------------------------------------------------------
> diff --git a/examples/xusb.c b/examples/xusb.c
> index c811353..c1b8fad 100644
> --- a/examples/xusb.c
> +++ b/examples/xusb.c
> @@ -598,8 +598,13 @@ static int test_device(uint16_t vid, uint16_t pid)
> handle = libusb_open_device_with_vid_pid(NULL, vid, pid);
>
> if (handle == NULL) {
> - perr(" Failed.\n");
> - return -1;
> + perr("Please install driver NOW!");
> + while(getchar() != 0x0A);
> + handle = libusb_open_device_with_vid_pid(NULL, vid, pid);
> + if (handle == NULL) {
> + perr(" Failed.\n");
> + return -1;
> + }
> }
>
> dev = libusb_get_device(handle);
> -------------------------------------------------------------------------
>
> Even as I am not going through a libusb reinit before trying to access
> the device after the driver has been installed, once the driver has
> been installed, libusb has no trouble communicating with the device.
>
> Attached is the full log of what I get when installing a WinUSB driver
> mid-test (look for "Please install driver NOW!"). You'll notice that
> we go straight into a libusb_get_device_list() after the driver has
> been installed, due to the second libusb_open... call, and everything
> behaves as expected.
>
> From these results, the only reason I'd see a need for the patch is if
> we want to address the potential issue of the driver installation
> ending right when we are in the middle of detecting devices, in which
> case we may get a different driver landscape between passes, but, with
> driver installation being so slow on Windows that's probably a one in
> a million chance (i.e. even if you wanted, you wouldn't be able to
> ensure that your driver installation ends right when you're issuing a
> libusb_get_device_list to be able to disturb it). Either that or
> you're probably issuing way more libusb_get_device_list calls than you
> should.
>
> All in all, I'm not seeing a real issue with being able to install a
> driver after libusb_init has been issued and access the device right
> now. Unless you can produce a scenario disproving what I currently see
> as a very low probability for the issue to manifest itself, I would
> still motion to wait for hotplug to review our enumeration behaviour.
>
Pete, thanks for testing this, and for your input.
The scenario I was looking at is:
libusb_get_device_list
device = go over the list of devices and find the one with
appropriate vid,pid
libusb_open(device)
if failed:
install libusb device driver
rescan devices (call libusb_get_device_list and
libusb_free_device_list)
libusb_open(device)
Maybe the problem can be solved in the application.
Likely I can unref it before driver installation, and find it again
after the installation.
That would be similar of using libusb_open_with_vid_pid.
I'll look into it.
Thanks,
Uri.
------------------------------------------------------------------------------
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
