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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Tuesday, June 16, 2015, 4:41:52 PM, you wrote:

> 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

Would a symlink to a sysfs or device node entry also be allowed ?

That way you can leverage the power of tools like udev or other device managers
and script the linkage based on a multitude of device properties 
(f.e. serial numbers, manufacturer id, device id, etc.).

Which can make it persistent across reboots or do other funky stuff with it,
according to ones needs.

--
Sander



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