Re: [Xen-devel] [PATCH v7 1/2] libxl: usb2 and usb3 controller support for upstream qemu

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Fabio Fantoni writes ("[PATCH v7 1/2] libxl: usb2 and usb3 controller support 
for upstream qemu"):
> Usage: usbversion=1|2|3 (default=0, no usb controller defined)
> Specifies the type of an emulated USB bus in the guest. 1 for usb1,
> 2 for usb2 and 3 for usb3, it is available only with upstream qemu.
> The old usb and usbdevice parameters cannot be used with this.
> 
> Changes from v6:
> - now usbversion cannot be used with usb and usbdevice parameters
> - now default is 0 (no usb controller defined)
> Will be used only with usb redirection (from spice client) and
> new usb passthrough (from dom0) with hotplug.
...
> +=item B<usbversion=NUMBER>
> + 
> +Specifies the type of an emulated USB bus in the guest. 1 for usb1,
> +2 for usb2 and 3 for usb3, it is available only with upstream qemu.
> +The old usb and usbdevice parameters cannot be used with this.
> +Default is 0 (no usb controller defined).
> +

I've reread the thread and I don't understand the backwards
compatibility implications here.

What is wrong with the usb and usbdevice parameters. ?

The "usb" parameter was able to turn on, and off, usb support in trad
qemu (and that was always usb1).  The previous default appears to be
0, i.e. off.  But if you said "usb=1" you would get usb1.  There
doesn't seem to be anything in your patch that makes that work with
qemu-upstream; instead you simply invent a totally new mechanism.

Why do you describe the usbdevice parameter as "old" ?

If you are formally deprecating "usb" and/or "usbdevice" you need to
replace them with something, and have a compatibility mechanism for
them, I think.

Perhaps I just don't understand the whole support matrix.  But even
if we are implementing partial support right now, we ought to
(a) clearly document what is deprecated and what isn't
(b) not deprecate anything until its replacement exists
(c) have an API and config design which can be coherently extended to
the full support matrix.

Thanks,
Ian.

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