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

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

[Claudio Fontana]

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.


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");
                 }
-- 
2.26.2

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

[Paolo Bonzini]

Queued, thanks.

Paolo

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

[Claudio Fontana]

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

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

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 589 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1123 bytes --]

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

[Markus Armbruster]

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?

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

[Claudio Fontana]

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

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

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

[Claudio Fontana]

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?

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

[Daniel P. Berrangé]

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

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

[Markus Armbruster]

Has this fallen through the cracks?

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

[Claudio Fontana]

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