Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages]

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 06/16/2015 02:37 PM, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"):
>> Remember that the path you gave in your previous e-mail isn't the path
>> for the *usb device*, it's the path for the *block device*.  It
>> contains a PCI address, but it looks like it also contains part of the
>> USB topology.  Are you sure that's actually a stable interface, or
>> does it just happen that on your hardware the discovery always happens
>> in the same order?
> 
> The block device is (in path terms) underneath the usb device,
> obviously.  Not all of that path is relevant to identifying the
> USB device.
> 
>> On my system /sys/bus/usb/devices/2-3.3 is a link to
>> /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3.3/.  This contains
>> the pci bus address, but it also contains the bus number, which we've
>> just said may be unstable across reboots.
> 
> You mean the 2 in `usb2' ?  I think that bus number is the bus number
> within the controller, not globally.

On the contrary:

$ ls -l usb*
lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb1 ->
../../../devices/pci0000:00/0000:00:1a.7/usb1/
lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb2 ->
../../../devices/pci0000:00/0000:00:1d.7/usb2/
lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb3 ->
../../../devices/pci0000:00/0000:00:1a.0/usb3/
lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb4 ->
../../../devices/pci0000:00/0000:00:1a.1/usb4/
lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb5 ->
../../../devices/pci0000:00/0000:00:1a.2/usb5/
lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb6 ->
../../../devices/pci0000:00/0000:00:1d.0/usb6/
lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb7 ->
../../../devices/pci0000:00/0000:00:1d.1/usb7/
lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb8 ->
../../../devices/pci0000:00/0000:00:1d.2/usb8/

$ ls /sys//devices/pci0000:00/0000:00:1d.7/ | grep usb
usb2/

In other words, the global bus enumeration leaks its way into the device
path; which means at very least the sysfs device path is potentially
unstable across reboots even if you include the pci controller it's on.

>> I suppose it might be possible to specify <buspci,port> -- the pci
>> address of the root bus, and the topology from there.  In theory I
>> guess that should be stable?
> 
> Yes.  The whole point of paths like this is that they are stable if
> the physical topology doesn't change.  So on my netbook
> 
>   /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1
> 
> always refers to the 1st MBR partition on logical device 0 on the USB
> storage device plugged into the USB port physically on the front left
> of the computer.

That would be great if it were true, but I'm not convinced that the
above path doesn't include a globally-enumerated bus number, which might
change across reboots if it's enumerated in a different order.

It may be that the format above is *not* based on the sysfs path of the
device; that the '0' immediately after the USB means "the first (and
perhaps only) controller at this PCI address".  In which case, yes,
having a string like this might be a unique identifier for a particular
port that would be stable across reboots.  That needs some investigation.

>> In any case, at the moment you're essentially inventing from whole
>> cloth a new way of specifying USB devices that (as far as I know)
>> isn't supported by any other program that uses USB.
> 
> If you can't specify the device by hardware path, you can't specify it
> deterministically.
> 
> And as you can see it _is_ supported by other programs that use USB.
> "mount" can use it!

Mount doesn't know anything about USB devices; all it knows are block
devices.  You might as well say that 'ls' knows about USB devices
because it can read files on a filesystem that resides on a USB stick.

I'm talking about programs that explicitly manipulate USB devices -- in
particular, those that may pass them through to a guest or seize them,
like libvirt, qemu, virtualbox, &c.

I'm not opposed to doing something new if it really is better.  But when
you find that a dozen other projects before you have done things one
way, you should at least take care before you decide to do something
radically different, to make sure that it's because you actually have
something better, and not because you've just missed something.

> I think the hardware path to the controller, at least, should be
> treated as an opaque OS-specific string.  It might have a different
> format on BSD.

If we can make an actual path that's stable across reboots, that would
certainly be a good thing.  But if it's not stable across reboots, it
has no advantage over the bus-port[.port.port] interface.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel