Re: query-command-line-options
Stefan, one question regarding your commit 40e07370f21 inline.
Peter Krempa <pkrempa(a)redhat.com> writes:
[...]
In fact I strive to eliminate it after your suggestions, but we
can't
still detect the few outstanding flags from anywhere else.
List of currently outstanding queries using query-command-line-options:
Let me translate these into English questions:
{ "fsdev", "multidevs",
QEMU_CAPS_FSDEV_MULTIDEVS },
Does -fsdev have parameter "multidevs"?
It does since v4.2.
Aside: not documented in -help.
9p seems entirely absent from the QAPI schema.
{ "machine", "hpet", QEMU_CAPS_MACHINE_HPET
},
Does -machine have parameter "hpet"?
Aside: not documented in -help.
Since this is a special case in q-c-l-o (commit 40e07370f21 qemu-config:
restore "machine" in qmp_query_command_line_options()), the actual
question is whether any non-abstract machine class has a property
"hpet".
PC machines do since v5.2. (the HPET device is older, but it wasn't
configured with a machine property until v5.2).
Aside: "any non-abstract machine class"... I think it used to be just
the current machine. See the code taken out by commit d8fb7d0969d (vl:
switch -M parsing to keyval). Accident in commit 40e07370f21? Stefan?
There's CONFIG_HPET, but I can't see offhand how it plays together with
the machine property.
We could check for the machine property directly: check the properties
of the machine class in question with qom-list-properties, e.g.
{"execute": "qom-list-properties",
"arguments": {"typename": "pc-q35-8.1-machine"}}
To find all non-abstract machine classes, use
{"execute": "qom-list-types", "arguments":
{"implements": "machine"}}
{ "sandbox", NULL, QEMU_CAPS_SECCOMP_SANDBOX },
Does option -sandbox exist?
It does since v1.2. If CONFIG_SECCOMP is off, actually using it is a
fatal error. Compiling out the option entirely would be more useful, I
guess.
Is this probe still useful?
{ "spice", NULL, QEMU_CAPS_SPICE },
Does option -spice exist?
Since v7.0, it exists when CONFIG_SPICE is on. I believe using it can
still fail when the module can't be loaded.
From v0.14 to v6.2 it exists even when CONFIG_SPICE is off, but
actually
using it is a fatal error.
{ "spice", "gl", QEMU_CAPS_SPICE_GL },
Does option -spice have parameter "gl"?
It does when CONFIG_OPENGL and CONFIG_OPENGL are both on (since v2.6).
query-display-options returns a value "gl" (since v2.12). *Maybe*
that's a suitable witness.
{ "spice", "rendernode",
QEMU_CAPS_SPICE_RENDERNODE },
Does option -spice have parameter "rendernode"?
It does when CONFIG_OPENGL and CONFIG_OPENGL are both on (since v2.9).
Maybe query-display-options can serve for this one, too.
{ "vnc", "power-control",
QEMU_CAPS_VNC_POWER_CONTROL },
Does option -vnc have parameter "power-control"?
It does since v6.0.
Aside: -help does not document any of its parameters.
query-display-options is not implemented for VNC. If we implement it,
it might become a suitable witness.