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

[Daniel P . Berrangé]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|