From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages] Date: Wed, 17 Jun 2015 05:59:53 +0200 Message-ID: <5580F0B9.2010806@suse.com> References: <1433906441-3280-1-git-send-email-cyliu@suse.com> <1433906441-3280-4-git-send-email-cyliu@suse.com> <21887.64856.265751.921367@mariner.uk.xensource.com> <558000E5.9000803@suse.com> <21888.1058.681450.470806@mariner.uk.xensource.com> <5580079D.6070007@suse.com> <21888.4161.841504.686364@mariner.uk.xensource.com> <21888.9902.709503.386019@mariner.uk.xensource.com> <558035B0.3070308@eu.citrix.com> <21888.18408.443895.592922@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap , Ian Jackson Cc: Wei Liu , Ian Campbell , Chunyan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org On 06/16/2015 06:34 PM, George Dunlap wrote: > On Tue, Jun 16, 2015 at 4:59 PM, Ian Jackson 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