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

[Jürgen Groß <jgross@xxxxxxxx>]

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel