Re: query-command-line-options

[Markus Armbruster <armbru@redhat.com>]

Stefan, one question regarding your commit 40e07370f21 inline.

Peter Krempa <pkrempa@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.