qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 5/5] query-command-line-options: return help mes


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 5/5] query-command-line-options: return help message for legacy options
Date: Tue, 11 Feb 2014 13:19:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

[Note cc: Eric]

Amos Kong <address@hidden> writes:

> Some legacy options that have arguments weren't added to
> vm_config_groups[], so query-command-line-options returns a
> NULL parameters infolist. This patch try to return help message
> for this kind of legacy options.
>
> Example:
>  {
>      "helpmsg": "\"-vnc display    start a VNC server on display\\n\"",
>      "parameters": [
>      ],
>      "option": "vnc"
>  },

Do we have prospective users for this feature?

> Signed-off-by: Amos Kong <address@hidden>
> ---
>  qapi-schema.json   | 5 ++++-
>  util/qemu-config.c | 3 +++
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 05ced9d..b3e6f46 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -3943,13 +3943,16 @@
>  # Details about a command line option, including its list of parameter 
> details
>  #
>  # @option: option name
> +# @helpmsg: help message for legacy options
>  #
>  # @parameters: an array of @CommandLineParameterInfo
>  #
>  # Since 1.5
>  ##
>  { 'type': 'CommandLineOptionInfo',
> -  'data': { 'option': 'str', 'parameters': ['CommandLineParameterInfo'] } }
> +  'data': { 'option': 'str',
> +            '*parameters': ['CommandLineParameterInfo'],
> +            '*helpmsg': 'str' } }
>  
>  ##
>  # @query-command-line-options:

Aha, here's the schema change missing in PATCH 3/5.

The schema needs to cover these kinds of options:

1. No argument

   { 'option': OPT-NAME }

2. QemuOpts argument

2a. with known parameters (QemuOptsList member desc[] not empty)

   { 'option': OPT-NAME,
     'parameters': [ { 'name': PAR-NAME, 'type': PAR-TYPE }, ... ] }

2b. with unknown parameters (desc[] empty)

   { 'option': OPT-NAME, parameters: [] }

3. Other argument

   { 'option': OPT-NAME, ? }

This patch adds 3.  We need to decide what we want there.

Any particular reason why we have to invent something new, and can't
simply fold it into 2b?

Note that I completely left out help strings, both on the option and on
the parameter level.  Both for brevity of presentation, and because I'd
like to see a use before we add them.

> diff --git a/util/qemu-config.c b/util/qemu-config.c
> index de233d8..a2def03 100644
> --- a/util/qemu-config.c
> +++ b/util/qemu-config.c
> @@ -176,6 +176,9 @@ CommandLineOptionInfoList 
> *qmp_query_command_line_options(bool has_option,
>              } else if (idx >= 0) {
>                  info->parameters =
>                      get_param_infolist(vm_config_groups[idx]->desc);
> +            } else if (info->has_parameters) {
> +                info->has_helpmsg = true;
> +                info->helpmsg = g_strdup(option_helpmsgs[i]);
>              }
>  
>              entry = g_malloc0(sizeof(*entry));



reply via email to

[Prev in Thread] Current Thread [Next in Thread]