Eric Blake <eblake@redhat.com> writes:
On 3/28/19 3:06 PM, Eric Blake wrote:
On 3/28/19 2:32 PM, Markus Armbruster wrote:
Markus Armbruster <armbru@redhat.com> writes:
Pavel Hrdina <phrdina@redhat.com> writes:
I'm glad that this is merged now and I wanted to start working on libvirt patches, but there is one big issue with this command, it's not introspectable by query-command-line-options. [...] Adding Markus to CC so we can figure out how to wire up the introspection for such command line options. [...] Command line options are actually defined in qemu-options.hx, which gets massaged into qemu_options[]. For each option, qemu_options[] gives us the option name (without leading '-'), and whether the option takes an argument.
This is less information per option than q-c-l-o provides now. Can we add it to its output anyway without confusing existing users? [...] Alternatives: [...] 5. Screw it, create a new query command to return just the information from qemu_options[].
Alternative 6:
Don't worry about patching q-c-l-o, but instead patch query-qemu-features:
https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg07584.html
Add a new feature: audiodev-command-line
That addition becomes both introspectible (since query-qemu-features options are introspectible regardless of their runtime state) and queryable (not that this feature needs runtime queries, but others might).
What is query-qemu-features about? Is it about QMP, or is it a grab-bag of ad hoc flags? To be discussed further in the thread you quoted.
And, since we're already proposing query-qemu-features for 4.0 for another reason, making it 2 reasons instead of 1 feels like extra justification for getting it done in a timely manner.
And answering myself after a bit more thought - the question is not just about "can we use the command line instead of envvars", but one step further of "once we are using the command line, what works in this release as opposed to added in later releases". So we still want introspection to land on the full QAPI types for audiodev, even if, for 4.0, we can't actually use QMP to change them. This means we at least need a QMP command that references the QAPI types (even if the command is named "x-audiodev-dummy" and always fails), so that the types at least make it into the introspection output, coupled with the query-qemu-features bit to state that even when we remove the hack of the x-audiodev-dummy command later, we can still use audiodev and scrape enough out of introspection for our needs.
Alternative 7: a hack to make QAPI type Audiodev visible in query-qmp-schema. query-qmp-schema shows exactly the types reachable from QMP commands and events. You can't look up a type by name there, you have to start at a command or an event. We'd have to create a suitable dummy. Recent precedence: commit e1ca8f7e1915496148f6e0ce1f7c2309af013312 Author: Gerd Hoffmann <kraxel@redhat.com> Date: Thu Nov 22 08:16:13 2018 +0100 qapi: add query-display-options command Add query-display-options command, which allows querying the qemu display configuration. This isn't particularly useful, except it exposes QAPI type DisplayOptions in query-qmp-schema, so that libvirt can discover recently added -display parameter rendernode (commit d4dc4ab133b). Works around lack of sufficiently powerful command line introspection. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> As much as I dislike such hacks, they can be the least bad option. Compare alternative 7. to 5.: 7. exposes complete syntactic information just for -audiodev, 5. exposes rudimentary syntactic information for all options. There's room for both. Doesn't mean we should do both, of course.