On 06/16/2015 12:41 PM, Ian Jackson wrote:
George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"):
Ian / Ian / Wei / Jim:
Hi.
3. Have the libxl layer accept both busid and bus:addr. Translate as
necessary and store in the libxl_device_usb struct.
...
The advantage of #3 internally is that the functions can do the
translation once (if necessary), and can then pass around the public
libxl_device_usb struct as-is without needing any extra parameters or
a separate libxl_device_usb_internal. The disadvantage, I think, is
that from an interface perspective, it's fairly pointless to have
both. busid doesn't really give you any better or more control than
the other, and it's not any more convenient for the user (in fact it's
less convenient because it's more difficult to find).
Is the busid more stable in the face of plug/unplug ? This is the
normal reason for a more path-like device specification.
If so then we must support it, even if it's not the usual way an
ordinary user would use it for a one-off. Otherwise you have to write
something in your config files for the VMs on your VM host, which will
break when someone plugs a keyboard into the `wrong' USB port.
Unfortunately the busid isn't stable at least across reboots.
qemu does support specifying a USB device via <vendorId>:<productId>,
which is stable even across reboots, but unfortunately it isn't
guaranteed to be unique (you can have plugged in two devices of the
same type).
My pvUSB backend in qemu will accept all three variants of device
specification, so may be libxl should do so, too.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel