DeviceInfo::bus_number() is wrong on Windows

[kevinmehall]

When adding two XHCI controllers in QEMU, devices on both are returning bus number 0. I think the DEVPKEY_Device_BusNumber may be the PCI bus number rather than anything specific to USB.

Libusb assigns bus numbers sequentially by iterating host controllers, but it's not clear that this ordering and thus numbering is deterministic.

I am wondering if the whole concept of bus number is a Linux-ism, though it turns out that macOS has something similar in the high 8 bits of locationID. Would it be better to expose the bus ID as a string rather than a number? Even Linux may be better served by a PCI path than a small integer in the presence of hotpluggable USB controllers such as Thunderbolt docks.

[martinling]

Since the nature of the ID can differ between platforms, how about a BusId type that wraps whatever the platform's internal representation is. That should guarantee the API remains portable.

That type could then implement Display so that programs can get something OS-appropriate to show the user.

[kevinmehall]

In #71 I just went with DeviceInfo::bus_id returning a string. It's a stringified number on Linux and macOS, and the host controller part of the first matching location path on Windows. The underlying busnum, locationID, or locationPaths are are also exposed with platform-specific methods. It could have been an opaque type, but a string seemed simpler than introducing more API surface.