Re: Command line QAPIfication and -readconfig

[Paolo Bonzini <pbonzini@redhat.com>]

On 11/11/20 16:29, Kevin Wolf wrote:
> 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.

Yeah, see the series I posted earlier.  There's some extra code but it's 
fairly well confined.

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

I mean that you could not easily turn

[boot-opts]
	order = "c"

into "-boot order=c" because the "boot-opts" -> "-boot" mapping is not 
written anywhere (except in code of course).

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

As usual, the choice will be:

1) deprecate and give a firm removal date, knowing that there won't be a 
replacement ready in time

2) deprecate with no plan to remove; use deprecation to justify breaking 
whatever is too complicated to maintain

3) refactor to keep the code at least readable and as simple as 
possible, desugaring to something completely new and more maintainable

For -set I'm leaning towards (2), keeping only "-set device" working as 
it does have users.  For the rest of vl.c I'm betting on building (3) 
around a core consisting of -blockdev, -netdev, -machine, -object, 
-accel and -device.

Paolo