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