[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, Jun 16, 2015 at 11:51 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
>> The "busid" interface that Chunyan is describing requires the caller
>> to find out that long name -- 2-3.1.2 -- rather than the traditional
>> short name (002:010).  Just accepting "2-3" is not sufficient.
>
>
> qemu with my patch will find the device only if the long name is used.
> So the "port" in qemu would be "3.1.2" in your example above.

Ah, right -- sorry, looking at the patch I saw that "port" was
converted using strtoul, but now I see that was "bus", and that "port"
is a string.  That's what I was missing.

> BTW: be careful with the syntax: x:y is used by qemu to specify a device
> by vendorId:productId, you should write "002.010" to use the short name
> above.

Yes, thanks for the reminder.  I knew there was some way to
distinguish bus.addr and vendor:device, but I'd forgotten the exact
semantics.

So as Juergen says, the typical way to write these would be:
- bus-port; e.g., 2-3.1.2  is bus=2, port=3.1.2.  Stable in topology,
not in device
- bus.addr: e.g., 2.10 is bus=2, address=10.  Unique every time a
device is plugged in (so no risk of aliasing, but not stable across
reboots)
- vendorid:deviceid: e.g., 1050:0111 is vendorid=1050, deviceid=0111.
Stable on device class (so same no matter when or where you plug it
in, but can't tell two identical devices apart).

 -George

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.