qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 2/2] query-command-line-options: query all th


From: Amos Kong
Subject: Re: [Qemu-devel] [PATCH v5 2/2] query-command-line-options: query all the options in qemu-options.hx
Date: Wed, 26 Mar 2014 19:16:15 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Mar 11, 2014 at 06:46:10PM -0600, Eric Blake wrote:
> On 03/06/2014 11:09 PM, Amos Kong wrote:
> > vm_config_groups[] only contains part of the options which have
> > parameters, and all options which have no parameter aren't added
> > to vm_config_groups[]. Current query-command-line-options only
> > checks options from vm_config_groups[], so some options will
> > be lost.
> > 
> > We have macro in qemu-options.hx to generate a table that
> > contains all the options. This patch tries to query options
> > from the table.
> > 
> > Then we won't lose the legacy options that weren't added to
> > vm_config_groups[] (eg: -vnc, -smbios). The options that have
> > no parameter will also be returned (eg: -enable-fips)
> > 
> > Some options that have parameters have a NULL desc list, some
> > options don't have parameters, and "parameters" is mandatory
> > in the past. So we add a new field "unspecified-parameters" to
> > present if the option takes unspecified parameters.
> > 
> > This patch also fixes options to match their actual command-line
> > spelling rather than an alternate name associated with the
> > option table in use by the command.
> > 
> > Signed-off-by: Amos Kong <address@hidden>
> > ---
> >  qapi-schema.json   |  9 +++++++--
> >  qemu-options.h     | 12 ++++++++++++
> >  util/qemu-config.c | 43 ++++++++++++++++++++++++++++++++++++-------
> >  vl.c               | 19 ++-----------------
> >  4 files changed, 57 insertions(+), 26 deletions(-)
 
> Based on the thread on v4, it sounds like this design is still not
> finalized, and won't make 2.0.  It sounds like once we start exposing
> all options, it would also be nice to show which options are sugar for
> other spellings.

It's not good to check if one option is sugar for other spellings from
help message. Does libvirt really need this information?

As I mentioned in V4 thread, we can add a tri-state:

+# @ArgumentStateType:
+#
+# Possible types for argument state.
+#
+# @no-argument: the option takes no argument
+#
+# @argument-with-parameters: the option takes argument with
+#                            unspecified parameters
+#
+# @argument-without-parameters: the option takes argument without
+#                               unspecified parameters
+#
+# Since 2.1
+##
+{ 'enum': 'ArgumentStateType',
+  'data': ['no-argument', 'argument-with-parameters',
+           'argument-without-parameters']
+}

I only implement the code by checking help message

  -option_name xxx,[xx=xx]\n

However, I will send a V6 later, let discuss based on it.


Thanks, Amos

> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index 193e7e4..fb7ca1b 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -4070,12 +4070,17 @@
> >  #
> >  # @option: option name
> >  #
> > -# @parameters: an array of @CommandLineParameterInfo
> > +# @parameters: array of @CommandLineParameterInfo, possibly empty
> > +# @unspecified-parameters: @optional present if the @parameters array is 
> > empty.
> 
> Blank lines between the two parameters, for consistency.
> 
> > +#                          If true, then the option takes unspecified
> > +#                          parameters, if false, then the option takes no
> > +#                          parameter (since 2.0)
> 
> So this will need to be changed to '(since 2.1)'.
> 
-- 
                        Amos.

Attachment: pgpujFH1mG8VU.pgp
Description: PGP signature


reply via email to

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