Re: [Qemu-devel] [libvirt] [PULL 04/14] audio: -audiodev command line option basic implementation

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 3/28/19 3:06 PM, Eric Blake wrote:
>> On 3/28/19 2:32 PM, Markus Armbruster wrote:
>>> Markus Armbruster <address@hidden> writes:
>>>> Pavel Hrdina <address@hidden> 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 <address@hidden>
    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 <address@hidden>

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.