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 <cfont...@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 :|
