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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Wed, Jul 25, 2018 at 11:43:29AM +0100, Anthony PERARD wrote:
> 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.
> 

This is fair enough.

> 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
> 

I think this is the mostly sustainable way going forward.

> 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).

How do they fix this sort of things? Do they reject removed options or
try (as best effort) to translate?

Wei.

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