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
