| Message ID | 20220908081441.7111-1-cfontana@suse.de |
|---|---|
| State | New |
| Headers | show |
| Series | [v3] audio: add help option for -audio and -audiodev | expand |
Queued, thanks. Paolo
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... Thanks, Claudio
No, there's nothing yet. Paolo 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... > > Thanks, > > Claudio > >
Paolo Bonzini <pbonzini@redhat.com> writes:
> No, there's nothing yet.
What about QOM introspection? Oh, we're not using QOM there. Would
QOMification be desirable?
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... >> >> Thanks, >> >> Claudio >> >> > No, there's nothing yet. > > Paolo > 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? Thanks, Claudio
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
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?
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
Has this fallen through the cracks?
On 9/16/22 12:43, Markus Armbruster wrote: > Has this fallen through the cracks? > I think it hasn't, Paolo responded with "queued, thanks", so from that comment I assume it has been picked up by Paolo in one of his queues. Thanks, Claudio
diff --git a/audio/audio.c b/audio/audio.c index 4f4bb10cce..6647ed5b1e 100644 --- a/audio/audio.c +++ b/audio/audio.c @@ -32,6 +32,7 @@ #include "qapi/qapi-visit-audio.h" #include "qemu/cutils.h" #include "qemu/module.h" +#include "qemu/help_option.h" #include "sysemu/sysemu.h" #include "sysemu/replay.h" #include "sysemu/runstate.h" @@ -2105,10 +2106,28 @@ static void audio_validate_opts(Audiodev *dev, Error **errp) } } +void audio_help(void) +{ + int i; + + printf("Available audio drivers:\n"); + + for (i = 0; i < AUDIODEV_DRIVER__MAX; i++) { + audio_driver *driver = audio_driver_lookup(AudiodevDriver_str(i)); + if (driver) { + printf("%s\n", driver->name); + } + } +} + void audio_parse_option(const char *opt) { Audiodev *dev = NULL; + if (is_help_option(opt)) { + audio_help(); + exit(EXIT_SUCCESS); + } Visitor *v = qobject_input_visitor_new_str(opt, "driver", &error_fatal); visit_type_Audiodev(v, NULL, &dev, &error_fatal); visit_free(v); diff --git a/audio/audio.h b/audio/audio.h index 27e67079a0..01bdc567fb 100644 --- a/audio/audio.h +++ b/audio/audio.h @@ -171,6 +171,7 @@ void audio_sample_from_uint64(void *samples, int pos, void audio_define(Audiodev *audio); void audio_parse_option(const char *opt); bool audio_init_audiodevs(void); +void audio_help(void); void audio_legacy_help(void); AudioState *audio_state_by_name(const char *name); diff --git a/qemu-options.hx b/qemu-options.hx index 31c04f7eea..04cd4dacfc 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -704,10 +704,11 @@ SRST ``-audio [driver=]driver,model=value[,prop[=value][,...]]`` This option is a shortcut for configuring both the guest audio hardware and the host audio backend in one go. - The host backend options are the same as with the corresponding - ``-audiodev`` options below. The guest hardware model can be set with - ``model=modelname``. Use ``model=help`` to list the available device - types. + The driver option is the same as with the corresponding ``-audiodev`` option below. + The guest hardware model can be set with ``model=modelname``. + + Use ``driver=help`` to list the available drivers, + and ``model=help`` to list the available device types. The following two example do exactly the same, to show how ``-audio`` can be used to shorten the command line length: @@ -721,6 +722,7 @@ ERST DEF("audiodev", HAS_ARG, QEMU_OPTION_audiodev, "-audiodev [driver=]driver,id=id[,prop[=value][,...]]\n" " specifies the audio backend to use\n" + " Use ``-audiodev help`` to list the available drivers\n" " id= identifier of the backend\n" " timer-period= timer period in microseconds\n" " in|out.mixing-engine= use mixing engine to mix streams inside QEMU\n" diff --git a/softmmu/vl.c b/softmmu/vl.c index dea4005e47..2f8eecf5c1 100644 --- a/softmmu/vl.c +++ b/softmmu/vl.c @@ -2842,11 +2842,16 @@ void qemu_init(int argc, char **argv, char **envp) audio_parse_option(optarg); break; case QEMU_OPTION_audio: { - QDict *dict = keyval_parse(optarg, "driver", NULL, &error_fatal); + bool help; char *model; Audiodev *dev = NULL; Visitor *v; - + QDict *dict = keyval_parse(optarg, "driver", &help, &error_fatal); + if (help || (qdict_haskey(dict, "driver") && + is_help_option(qdict_get_str(dict, "driver")))) { + audio_help(); + exit(EXIT_SUCCESS); + } if (!qdict_haskey(dict, "id")) { qdict_put_str(dict, "id", "audiodev0"); }
add a simple help option for -audio and -audiodev to show the list of available drivers, and document them. Signed-off-by: Claudio Fontana <cfontana@suse.de> --- audio/audio.c | 19 +++++++++++++++++++ audio/audio.h | 1 + qemu-options.hx | 10 ++++++---- softmmu/vl.c | 9 +++++++-- 4 files changed, 33 insertions(+), 6 deletions(-) v2 -> v3: use AudiodevDriver_str and AUDIODEV_DRIVER__MAX to loop over drivers instead of audio_prio_list (Volker). v1 -> v2: also extend the help to -audio. -audio help -audio driver=help -audiodev help will all show the same results.