[Spice-devel] [spice-gtk PATCH 0/9] Windows: identify USB devices by vid:pid instead of bus.address

[Hans de Goede]

Hi,

On 03/27/2013 04:33 PM, Uri Lublin wrote:
> On 03/25/2013 12:17 PM, Hans de Goede wrote:
>> Hi,
>
> Hi Hans,
>
> Thanks for reviewing.
>
>>
>> On 03/25/2013 11:01 AM, Uri Lublin wrote:
>>> rhbz#842816
>>>
>>> It seems that sometimes a USB device's bus.address is changing after
>>> installation of WinUSB driver for that device.
>>> So instead use vid:pid which are consistent across driver installation.
>>>
>>> The switch to using vid:pid is done in patch 8/9.
>>>
>>> Some code reuses variables named "bus" and "address" to hold vid and pid
>>> values. If people think this should be changed to new variables names (ifdefed)
>>> and/or new function instead of spice_usb_device_manager_get_udev_bus_n_address
>>> let me know.
>>>
>>> Using two devices with the same vid:pid on the same Windows client is already
>>> not supported, since Windows installs USB drivers for specific devices
>>> based on their vid:pid
>>
>> Hmm, I'm not very happy with the approach you've chosen here. Just because
>> usbclerck / our driver swapping magic currently does not support having devices
>> with identical vid:pid is not a good reason to add the same problem to other
>> parts of the code. The contrary is true really, this is something which we
>> should try to fix, not make worse.
>
> I'm only trying to fix the Windows bus.addr inconsistency problem.
> I don't think that makes things worse, but better.
> I agree that this patch-set inserts the existing driver limitation
> (of using two devices with the same vid:pid) into spice-gtk,
> for Windows (and keeps Linux as is).
> This limitation already exists for Windows clients, and
> we can remove it from spice-gtk in the future if needed.

Ok, so lets split the discussion in 2:

1) What do we need today

Today we need a way to work around the bus.addr pair not being stable
for a single device under Windows, since today we already do NOT
support using multiple devices with the same vid:pid, using vid:pid
(iow this patchset) would be an acceptable solution, but only today!

2) Where do we want to be tomorrow

"Tomorrow" we will hopefully be using filter drivers, and hopefully
then we don't need the whole driver install dance (even for new devices
which were never plugged in before?), and then we can remove a whole
bunch of windows specific "murk" from the spice-gtk code for usb
handling.

So if we can agree on this being a temporary thing, then I can agree
with the vid:pid approach *for now*, but this really really needs to
be replaced / fixed in the near future.

So with this clear, and assuming you will agree, let me actually really
review this patch-set :)


Some remarks on alternative approaches below, but lets just go with
vid:pid for now.

>
>>
>> Have you tried using libusb_get_port_path? I know that is sensitive to
>> device swap races on the same port, so how about using a combination of
>> libusb_get_port_path + vid & pid to identify a device?
>
> I did not try using libusb_get_port_path.
> It may be a better solution:
>   - It works the same for both Linux and Windows.
>   - It fixes the Windows problem (all should be consistent through driver install)
It may seem to fix the Windows problem, but if a device gets removed, and
then replaced by another one while the driver install is happening, then
just using the port-path is not enough, we could combine it with vid:pid,
but then 2 identical devices (from a vid:pid) pov get swapped, we would
miss that, so this is still not ideal.

>   - It is a more robust solution for Linux (is it really ?).
>     + Wouldn't device_address change upon device_swap ?

bus.addr is 100% reliable on Linux, replacing it with bus + port-path
introduces the issues we're having on Windows without any gains (other then
unification of the code.

> It's also requires a bit more memory.
>
> We'd need to use bus_number as part of device identification.
> There may be two different devices on two different buses that have
> the same port_path (at least that's the case on Linux).

Ah, good one, so you need bus_number + port_path to uniquely identify
a port, note this is identifying a port, not what is plugged in hence
the need to also check vid:pid.

Regards,

Hans