qemu-devel
[Top][All Lists]
Advanced

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

Re: Command line QAPIfication and -readconfig


From: Kevin Wolf
Subject: Re: Command line QAPIfication and -readconfig
Date: Wed, 11 Nov 2020 11:35:50 +0100

Am 11.11.2020 um 11:14 hat Daniel P. Berrangé geschrieben:
> On Wed, Nov 11, 2020 at 10:24:40AM +0100, Kevin Wolf wrote:
> > Hi,
> > 
> > while QAPIfying the chardev configuration, I noticed that dropping
> > QemuOpts completely in vl.c would break -readconfig. So for now I'm
> > stopping at the point where internal interfaces are fully QAPIfied and
> > the QemuOpts interfaces are only a thin wrapper around them.
> > 
> > But do we already have a plan what to do with -readconfig? Should we
> > just deprecate it in 5.2 so we can complete the work in 6.1 and leave
> > vl.c unconverted for now? Or should we rather convert half of vl.c and
> > keep both QAPI and QemuOpts around for the same option for now?
> 
> -readconfig is a little complex because we're not trying to remove the
> ability to use a config file, instead we want to switch to a different
> type of config file.
> 
> IOW, it is about replacement, rather than removal, of functionality.

That's the long term plan, but we can only add that different type of
config file once all options are QAPIfied and QAPIfication has the
problem of having to deal with -readconfig.

> Normally we would not mark something as deprecated unless its replacement
> is ready, because telling people "stop using this but the replacement
> doesn't exist yet" is not a nice message as there is no action users can
> take to deal with the deprecation.

But there is a replacement: Put everything back into the command line
and keep it in a shell script. Config files with -readconfig were never
complete enough to fully describe a VM, so it's not too unlikely that
you'll already have that script anyway.

> We might question whether -readconfig has any users but I would note
> that our own documentation illustrates its usage, and provides several
> example configs
> 
> $ git grep docs -- -readconfig
> config/ich9-ehci-uhci.cfg:# You can pass this file directly to qemu using the 
> -readconfig
> config/mach-virt-graphical.cfg:#     -readconfig mach-virt-graphical.cfg \
> config/mach-virt-serial.cfg:#     -readconfig mach-virt-serial.cfg \
> config/q35-emulated.cfg:#     -readconfig q35-emulated.cfg
> config/q35-virtio-graphical.cfg:#     -readconfig q35-virtio-graphical.cfg
> config/q35-virtio-serial.cfg:#     -readconfig q35-virtio-serial.cfg \
> devel/blkdebug.txt:follows the same .ini-like format used by QEMU's 
> -readconfig option, and
> system/qemu-block-drivers.rst.inc:in a configuration file provided via 
> '-readconfig' or directly on the
> system/qemu-block-drivers.rst.inc:    -readconfig iscsi.conf
> usb2.txt:    qemu -readconfig docs/config/ich9-ehci-uhci.cfg
> 
> 
> IIUC, even with just the internal interface conversion to QAPI we're able
> to introduce our new config file functionality in whatever manner we like.
> 
> Thus removing QemuOpts from vl.c should not be a blocker for other work,
> it is more of a "nice to have" from pov of cleaning up code.
> 
> IOW, I'd suggest we focus effort on introducing the new config file format
> based on QAPI first, and once that exists, then convert these sample
> config files in docs/config, and deprecate -readconfig.

Fine with me. That would make introducing the new config file format a
priority, though, even if it can't support every option yet (similar to
-readconfig). I didn't have the impression so far that we are planning
to do that. Is anyone working on it?

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]