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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Sep 09, 2022 at 04:27:34PM +0200, Claudio Fontana wrote:
> 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?

Sort of, its a gross hack. By adding query-audiodev for querying the
config of -audiodev command line options, the audiodefv backend types
get added to the QMP schema. You can thus query for whether a backend
exists using query-qmp-schema'


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 :|