Amos Kong <akong@redhat.com> writes:
On Wed, Mar 26, 2014 at 02:15:18PM +0100, Markus Armbruster wrote:
Amos Kong <akong@redhat.com> writes:
On Fri, Mar 07, 2014 at 10:54:09AM +0100, Markus Armbruster wrote:
Eric Blake <eblake@redhat.com> 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. [...]