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