[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 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |