Re: [libvirt] [Qemu-devel] [PULL 04/14] audio: -audiodev command line option basic implementation
Eric Blake <eblake(a)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(a)redhat.com> writes:
>>> Pavel Hrdina <phrdina(a)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(a)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(a)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.