From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chun Yan Liu" Subject: Re: [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages] Date: Thu, 18 Jun 2015 00:24:36 -0600 Message-ID: <5582D4A402000066000D885D@relay2.provo.novell.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> <5580F0B9.2010806@suse.com> <55814B9F.6070909@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55814B9F.6070909@eu.citrix.com> Content-Disposition: inline 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 , Juergen Gross Cc: Jim Fehlig , Simon Cao , Wei Liu , Ian Campbell , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org >>> On 6/17/2015 at 06:27 PM, in message <55814B9F.6070909@eu.citrix.com>, George Dunlap wrote: > On 06/17/2015 04:59 AM, Juergen Gross wrote: > > 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_i > d.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. > > Right -- I think I had come to the conclusion that would probably be the > case later yesterday evening. Glad to have it confirmed. > > So in addition to our other identifiers, stealing udev's naming scheme > should work, and would be useful. > > The next challenge would be how to implement it effectively. It's > already udev's job to make sure that a string is unique -- as much as > possible we want to leverage their efforts, rather than re-implementing > our own. > > One thing that Ian suggested was that we could add a udev rule that > would create links from the ID_PATH of the usb device into the sysfs > device node. (Both seem to be available in the udev rule environment.) > That would allow us to easily translate the ID_PATH into the other > things we might want (bus-port, bus.addr, &c) and vice versa. > > But I think all that will certainly not be done by the feature freeze. > > The core functionality of Chunyan's series, wrt the pvusb functionality > is complete; as with my HVM series before, it's mainly the interface > that is being discussed. > > There are two options here: Chunyan could try to implement the interface > we've been discussing here (assuming that she doesn't have any > objections to what we've described); No, I don't have any objections. I can do that. - Chunyan > or, I could take Chunyan's series, > try to implement what we've been talking about, and then add in the HVM > functionality as well. > > What does everyone think? > > -George > > > >