[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages]
On 06/16/2015 06:34 PM, George Dunlap wrote: On Tue, Jun 16, 2015 at 4:59 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages]"):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:What seems to be the case -- that it contains the global bus, or not?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.It looks like that's constructed in udev: http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-path_id.c See handle_usb() (line 542) in particular. If I'm reading it right, what it basically does it take the [bus]-[port], and replace it with usb-0:[port]. (IOW, the '0' is hard-coded.) Also, if I'm reading it right, this won't work properly for Juergen's system that has two USB devices at the same pci address -- they'll both end up resolving to [pciaddr]-usb-0:[whatever]. Juergen -- can you give this a try? Run "udevadm info" on the two USB busses that share the same PCI slot, and see if the ID_PATH is the same for both? This was the correct question. :-) The ID_PATH is the same, but: It turns out that the two busses are for one physical hcd. One is the bus for USB 3.0, the other one for USB 2.0. I guess the bus is just selected by the capability of the plugged in device. So the [port] in "usb-0:[port]" is unique across the two logical busses. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |