[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |