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

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 6/17/2015 at 06:27 PM, in message <55814B9F.6070909@xxxxxxxxxxxxx>, 
>>> George
Dunlap <george.dunlap@xxxxxxxxxxxxx> 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 
> >> <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_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 
>  
>  
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel