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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API [and 
1 more messages]"):
> On 06/16/2015 02:37 PM, Ian Jackson wrote:
> > George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb 
> > API"> >> /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:
> [...]

Oh dear.

> 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.

How unhelpful.

> > 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.

That does seem to be the case:

zealot:~> ls -al 
/dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1
lrwxrwxrwx 1 root root 10 Jun 16 16:45 
/dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sdc1
zealot:~> ls -al /sys/class/block/sdc
lrwxrwxrwx 1 root root 0 Jun 16 16:45 /sys/class/block/sdc -> 
../../devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host19/target19:0:0/19:0:0:0/block/sdc/
zealot:~>

Observe that the sysfs path contains not only `usb1' (which isn't
stable) but also `host19' which is also not stable.  If I unplug and
replug:

zealot:~> ls -al 
/dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1
lrwxrwxrwx 1 root root 10 Jun 16 16:49 
/dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sdc1
zealot:~> ls -al /sys/class/block/sdc
lrwxrwxrwx 1 root root 0 Jun 16 16:50 /sys/class/block/sdc -> 
../../devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host20/target20:0:0/20:0:0:0/block/sdc/
zealot:~>

Looking at the output of udevadm monitor --property for sdc1 (on
another plug):

DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0/host22/target22:0:0/22:0:0:0/block/sdc/sdc1
ID_PATH=pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
ID_PATH_TAG=pci-0000_00_1d_7-usb-0_1_1_0-scsi-0_0_0_0

I don't know where that ID_PATH comes from.

I can't seem to find anything relevant in my
/sys/devices/pci0000:00/0000:00:1d.7

> > 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.

Yes.

Ian.

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