Re: Command line QAPIfication and -readconfig

[Kevin Wolf]

Am 11.11.2020 um 14:06 hat Paolo Bonzini geschrieben:
> 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

Ah, I wasn't even aware of this type of option, so thanks for mentioning
it here. (It makes sense to me.)

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

Yes, no question this is doable, it just requires some extra code for
each option instead of reusing something existing. But it's not too bad
as QDicts are at least slightly more natural for a QAPI based interface
than QemuOpts.

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

Whether it's a callback or an iterator shouldn't make a big difference.
blkdebug can easily use either.

And whether the data is QemuOpts, QDict or a string shouldn't make much
of a difference either because it can just run a visitor on any of them
and get back the QAPI BlkdebugFoo types that it should be using 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.

Hm, where is the difference between both? The QEMU_OPTION_boot case
seems to just directly parse optarg into "boot-opts" with
qemu_opts_parse_noisily(), which should be the same as -readconfig does
with its input, no?

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

Even if we queue the -readconfig deprecation only for 6.0, that's still
fine. I just don't want to discuss one year from now how we should have
deprecated it long ago.

Kevin