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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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_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.

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); 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