[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 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? -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |