[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] libxl: Handle deprecation of QEMU's -usbdevice



On Wed, Jul 25, 2018 at 09:38:20AM +0100, Wei Liu wrote:
> On Thu, Jul 19, 2018 at 06:29:29PM +0100, Anthony PERARD wrote:
> > -usbdevice is deprecated as of QEMU 2.10.
> > 
> > This patch replace the few options documented in xl.cfg(5) by the
> > recommanded syntax. And if the option isn't recognize, simply use
> > -usbdevice with a warning, the options isn't entirely removed from QEMU
> > upstream.
> > 
> > Also, remove from the manual the sentence inviting to read QEMU's
> > documentation.
> > 
> > Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> > ---
> >  docs/man/xl.cfg.pod.5.in |  3 --
> >  tools/libxl/libxl_dm.c   | 66 +++++++++++++++++++++++++++++++++++++---
> >  2 files changed, 61 insertions(+), 8 deletions(-)
> > 
> > diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> > index 099a28dc7a..74375e0225 100644
> > --- a/docs/man/xl.cfg.pod.5.in
> > +++ b/docs/man/xl.cfg.pod.5.in
> > @@ -2468,9 +2468,6 @@ write "host:8.2".
> >  
> >  The form usbdevice=DEVICE is also accepted for backwards compatibility.
> >  
> > -More valid options can be found in the "usbdevice" section of the QEMU
> > -documentation.
> > -
> 
> Does this mean we intend to only support the options listed in
> xl.cfg(5)?

I have no idea which options are supported. I can leave that extra
sentence in the manual, as the meaning change over time, outside of our
control. Right know, on my machine, in `man qemu`, it means
mouse/tablet/braille + it is deprecated.

Having a look into SUPPORT.md, I should also parse "mouse", as both
usbmouse and usbtablet are supported. There is also "Host USB
passthrough" for which support as been removed upstream. That's it,
nothing else is supported according to the document.

> If so, I think we should make clear here -- this is a regression. And
> tell users if they have appended their own options they should take
> actions, like using device_model_extra_args or something else (?).

"something else" could be send a msg to xen-devel, so that we can add
support for it, extra_args is a nice work around, at least, user should
know that the options might break if qemu change.

Also, you said we could parse few know options and reject the rest:
https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg02770.html

As for what to do to tell the users to use the kitchen sink, I have no
idea.

> How does libvirt handle QEMU option deprecation?

I don't think they handle it very well. I think it's basicaly when the
deprecated option is removed from QEMU that they notice libvirt need to
be fixed (That's what I got from reading a thread on qemu-devel).

Thanks,

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.