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

From: George Dunlap <George.Dunlap@eu.citrix.com>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: "Jürgen Groß" <jgross@suse.com>, "Wei Liu" <wei.liu2@citrix.com>,
	"Ian Campbell" <ian.campbell@citrix.com>,
	"Chunyan Liu" <cyliu@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"Jim Fehlig" <jfehlig@suse.com>,
	"Simon Cao" <caobosimon@gmail.com>
Subject: Re: [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages]
Date: Tue, 16 Jun 2015 17:34:21 +0100	[thread overview]
Message-ID: <CAFLBxZZ=6uQ_SGeJ1bGySv87MJGbj1qzb+++DDYGmga8iv7W8w@mail.gmail.com> (raw)
In-Reply-To: <21888.18408.443895.592922@mariner.uk.xensource.com>

On Tue, Jun 16, 2015 at 4:59 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> 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