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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Jun 16, 2015 at 1:02 PM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"):
>> So it sounds like we're converging on "Allow multiple ways to specify
>> the interface", with at least the following fields:
>> - bus (int - 1,2,3, &c)
>> - port (string - 2.1.3, &c)
>> - address/devnum (int)
>> - vendorid (uint16_t)
>> - deviceid (uint16_t)
>
> You're missing the full device path from that list.  Typically that
> will include at least one pci bus address.

I'm not sure what constitutes a "full device path".  Is that defined somewhere?

Remember that the path you gave in your previous e-mail isn't the path
for the *usb device*, it's the path for the *block device*.  It
contains a PCI address, but it looks like it also contains part of the
USB topology.  Are you sure that's actually a stable interface, or
does it just happen that on your hardware the discovery always happens
in the same order?

On my system /sys/bus/usb/devices/2-3.3 is a link to
/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3.3/.  This contains
the pci bus address, but it also contains the bus number, which we've
just said may be unstable across reboots.

I suppose it might be possible to specify <buspci,port> -- the pci
address of the root bus, and the topology from there.  In theory I
guess that should be stable?

In any case, at the moment you're essentially inventing from whole
cloth a new way of specifying USB devices that (as far as I know)
isn't supported by any other program that uses USB.

 -George

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