All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: jsnow@redhat.com, "Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: Command line QAPIfication and -readconfig
Date: Wed, 11 Nov 2020 14:06:57 +0100	[thread overview]
Message-ID: <0471d35c-6fbc-c3e8-a2c3-b627a1ec2ece@redhat.com> (raw)
In-Reply-To: <20201111125307.GC3898@merkur.fritz.box>

On 11/11/20 13:53, Kevin Wolf wrote:
> QDicts are one step closer to the final result, but would also have to
> be processed separately as they need only half of the processing that
> command line options need. Eventually, qobject_input_visitor_new_str()
> is what we want to use to parse strings directly into QAPI objects, and
> QDicts are only an internal intermediate result there.

To be clearer, the processing would look like this:

- both qemu_config_parse and qemu_read_config_file call a static 
function qemu_config_foreach

- qemu_config_foreach builds a QDict and passes it to a callback

qemu_read_config_file receives a callback argument from vl.c, while 
qemu_config_parse uses a default callback that does qemu_opts_create and 
qemu_opts_absorb_qdict.

The callback in vl.c does this:

1) for a keyval-based non-mergeable option (e.g. -object) -> do 
qdict_crumple and store the QDict for later processing.

2) for a keyval-based mergeable option (e.g. -M) -> do qdict_crumple and 
merge with previous command-line options using a new function keyval_merge

3) for non-keyval options -> forward to the default callback used by 
qemu_config_parse.


Later on, keyval-based options are parsed into QAPI objects or QOM 
properties using qobject_input_visitor_new_keyval.

> So while it's even uglier, maybe what we should do with -readconfig is
> convert it back to strings and then run the result through the normal
> command line processing? This would get rid of the special cases.

That would be more or less doable but there are two problems: 1) the 
-readconfig code is used for blkdebug too, so you would need some kind 
of callback anyway 2) converting to strings is not entirely trivial due 
to e.g. different spelling between the "-boot" command line option and 
the "boot-opts" group.

> Both options are probably only hacks for the short term, so either way I
> think I'd still prefer deprecating -readconfig now, in favour of command
> line options as long as we don't have a QAPI based config file.

"Now" is a bit too late for 5.2.  I would like to deprecate "-set" for 
that matter too, but it's so obscure that I'm thinking of just dropping 
it in 6.0.

Paolo



  reply	other threads:[~2020-11-11 13:08 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
2020-11-11 11:07     ` Paolo Bonzini
2020-11-11 12:53       ` Kevin Wolf
2020-11-11 13:06         ` Paolo Bonzini [this message]
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=0471d35c-6fbc-c3e8-a2c3-b627a1ec2ece@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@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.