Re: [Qemu-devel] [PATCH v4 2/2] query-command-line-options: query all the options in qemu-options.hx

[Markus Armbruster]

Amos Kong <address@hidden> writes:

> On Wed, Mar 26, 2014 at 02:15:18PM +0100, Markus Armbruster wrote:
>> Amos Kong <address@hidden> writes:
>> 
>> > On Fri, Mar 07, 2014 at 10:54:09AM +0100, Markus Armbruster wrote:
>> >> Eric Blake <address@hidden> writes:
>> >> 
>> >> > On 03/05/2014 07:36 PM, Amos Kong wrote:
>> >> >> vm_config_groups[] only contains part of the options which have
>> >> >> argument, and all options which have no argument 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 argument will also be returned (eg: -enable-fips)
>> >> >> 
>> >> >> Some options that have argument have a NULL desc list, some
>> >> >> options don't have argument, and "parameters" is mandatory
>> >> >> in the past. So we add a new field "argument" to present
>> >> >> if the option takes unspecified arguments.
>> >> >
>> >> > I like Markus' suggestion of naming the new field
>> >> > 'unspecified-parameters' rather than 'argument'.
>> >  
>> > Hi Markus,
>> >
>> >> Looking again, there are more problems.
>> >> 
>> >> 1. Non-parameter argument vs. parameter argument taking unspecified
>> >>    parameters
>> >> 
>> >>    Example: -device takes unspecified parameters.  -cdrom doesn't take
>> >>    parameters, it takes a file name.  Yet, the command reports the same
>> >>    for both: "parameters": [], "argument": true.
>> >> 
>> >>    Looks like we need a tri-state: option takes no argument, QemuOpts
>> >>    argument, or other argument.
>> >
>> > '-cdrom' is the 'other argument' == 'Non-parameter argument'?
>> 
>> Let me clarify my terminology:
>> 
>> * A "parameter argument" is an option argument of the form KEY=VALUE,...
>>   Since parameter arguments should always be parsed with QemuOpts[*], I
>>   use the term "QemuOpts argument" interchangeably.
>> 
>> * A "non-parameter argument" or "other argument" is an option argument
>>   that doesn't use this form.
>> 
>> Does that answer your question?
>
> Got it, thanks.
>  
>> > We can use a enum state.
>> 
>> I'm not sure I got that.
>> 
>> > |  { 'enum': 'ArgumentStateType',
>> > |    'data': ['no-argument', 'unspecified-parameters-argument',
>> > |             'non-parameter-argument']
>> > |  }
>
>
>         {'enum': 'ArgumentStateType',
>          'data': ['no-argument', 'qemuopts-argument', 'non-param-argument']
>         }
>
>      no-argument:         -enable-kvm
>      qemuopts-argument:   -boot order=c,menu=on
>      non-param-argument:  -cdrom file
>
>
>      I don't know if it's the tri-state you suggested in previous reply.

It is.

Maybe

    { 'enum': 'OptionArgumentKind',
      'data': ['none, 'QemuOpts, 'other'] }

The type name makes clear it's about *option* argument, and avoids
connotation with schema types or C types.  The enum value names are
short and to the point.

[...]