Re: [PATCH v3] audio: add help option for -audio and -audiodev

[Claudio Fontana]

On 9/9/22 15:50, Daniel P. Berrangé wrote:
> On Fri, Sep 09, 2022 at 03:41:22PM +0200, Claudio Fontana wrote:
>> On 9/9/22 00:05, Paolo Bonzini wrote:
>>> Il gio 8 set 2022, 15:47 Claudio Fontana <cfontana@suse.de> ha scritto:
>>>
>>>> On 9/8/22 11:39, Paolo Bonzini wrote:
>>>>> Queued, thanks.
>>>>>
>>>>> Paolo
>>>>>
>>>>>
>>>>
>>>> Thanks. When it comes to programmatic checks about what QEMU supports in
>>>> terms of audio,
>>>>
>>>> is there something that can be done with QMP?
>>>>
>>>> I checked the QMP manual at:
>>>>
>>>>
>>>> https://qemu.readthedocs.io/en/latest/interop/qemu-qmp-ref.html#qapidoc-2948
>>>>
>>>> but in the "Audio" section there is a bunch of Objects and enums defined,
>>>> but no command to query them...
>>>>
>>> No, there's nothing yet.
> 
> You're now reminding me of the patch I sent a while ago for reporting
> audiodev backends and then completely forgot to followup on
> 
>   https://mail.gnu.org/archive/html/qemu-devel/2021-03/msg00656.html
> 
> 
>> Interesting. What about Display (ie ui-*) ? I mean how do I figure out from, 
>> say, libvirt,
>> everything that QEMU can do in terms of display, which drivers are actually 
>> installed?
>>
>> Same for block...
>>
>> with the increasing modularization of QEMU we should I presume strengthen 
>> the discoverability of QEMU capabilities right?
>> This way we can configure once, and install just what is needed to match the 
>> user requirements, or distro variant.
>>
>> As Markus mentioned maybe a more general solution would be to have these 
>> things as qom objects so that a
>>
>> qom-list-types
>> can be used to get all 'audiodev' types, or all 'display' types, or all 
>> 'block' types and solve the problem this way?
> 
>> Is there a more general problem / solution that I am not seeing?
> 
> In an idealized world (where we can ignore the reality of our
> existing legacy codebase) I think all backends would simply
> be QOM objects, and created with -object, avoiding the need for
> any backend type specific CLI args like -audiodev / -netdev / etc.
> 
> This would actually also extend to frontends, devices, cpus,
> machine types etc all being objects, ought to be creatable via
> -object, not requiring -device, -machine.
> 
> If we lived in the world where everything was a QOM Object,
> then qom-list-types would serve as the universal detection
> mechanism for everything.
> 
> Back in our current reality of pre-existing legacy code though,
> we have to be a little more pragmattic. If we can make things
> into QOM objects that work with -object / qom-list-types that's
> great, but if it is too much work we'll just have to create other
> QMP commands for querying, such as the query-audiodev patch.
> 
> 
> With regards,
> Daniel

Hmm the patch I am seeing though says that it

"reflects back the list of configured -audiodev command line options".

Maybe we are saying the same thing, but maybe we aren't,
what we are actually trying to achieve is to probe which audiodev drivers are 
available, either built-in or loaded as modules.
Same for display, block, etc.

You are instead trying to fetch the command line options?