[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |