All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: pbonzini@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org,
	armbru@redhat.com
Subject: Re: Command line QAPIfication and -readconfig
Date: Wed, 11 Nov 2020 11:35:50 +0100	[thread overview]
Message-ID: <20201111103550.GB3898@merkur.fritz.box> (raw)
In-Reply-To: <20201111101407.GD906488@redhat.com>

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	other threads:[~2020-11-11 10:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-11  9:24 Command line QAPIfication and -readconfig Kevin Wolf
2020-11-11 10:14 ` Daniel P. Berrangé
2020-11-11 10:35   ` Kevin Wolf [this message]
2020-11-11 11:07     ` Paolo Bonzini
2020-11-11 12:53       ` Kevin Wolf
2020-11-11 13:06         ` Paolo Bonzini
2020-11-11 15:29           ` Kevin Wolf
2020-11-11 16:39             ` Paolo Bonzini
2020-11-12 14:14     ` Andrea Bolognani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201111103550.GB3898@merkur.fritz.box \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.