On Tue, 16 Feb 2021 at 13:44, Paolo Bonzini <firstname.lastname@example.org> wrote:
> On 16/02/21 14:36, Peter Maydell wrote:
> > Broadly, I think that being able to say 'foo' when foo is a
> > boolean option being set to true is obvious and nice-to-use
> > syntax, and I don't really want it to go away. 'nofoo' for
> > 'foo=false' is much less obvious and I'm happy if we only
> > support it as a special-case for 'nowait'.
> It really depends on what the default "-M pc,nographics" arguably makes
> sense too (more so than "-M pc,graphics" since true is the default).
Is anybody using 'pc,nographics' ? google didn't find any examples.
It's just an example that the prevalence of "nowait" over "wait" is simply because the default of "server" is false while the default of "wait" is true. Any boolean option whose default is true could benefit from a "no"-prefixed short form. But I am pretty sure that there are users in the wild for noipv4 or noipv6.
> How do you propose to resolve the issues and ambiguities in the grammar?
> 1) due to QemuOpts not understanding types, you can specify "serial" and
> get "serial=on" instead
We should fix this by plumbing through the type information,
so that we only allow 'foo' to mean 'foo=on' if foo is really
a boolean (or other type that specifies that it has similar behaviour).
There's already type information for non-freeform options (those where the QemuOptsList includes the list of valid suboptions, such as -smp or -m). Adding it for freeform options (-M, -device) is basically impossible since the type information comes from a mix of QAPI schema, QOM class declarations and C code. One would basically have to do an incremental visit of the schema (assuming there is a schema, and it's not just C code) during the parsing. This is understandably not something I plan to spend time on.
I could change QemuOpts to allow short forms for non-freeform option groups, and turn -chardev into a non-freeform option. That would solve the immediate issue with chardev. But I agree that consistent behavior is better, so I don't think this is a good idea either.
> 2) with a parser that understands other types than strings, you would
> not be able to specify "-M kernel-irqchip" because it would be converted
> to the boolean "true" and not the enum "'on'"
We should decide whether 'kernel-irqchip' has a type that
allows 'no parameter specified' => 'use this default value'
or not, and if we go for the latter use whatever default value
the backend expects.
I don't understand, the point of short-form options is to use a *non-default* value. (In other words, the affirmative short form would typically be used to specify true when the default is false).
(And probably "boolean-and-an-extra-value"
types should allow the boolean bit to be specified in all the
same ways that a plain-old-boolean is.)
> 3) one is not be able to specify "-M pc" -M usb" because the second
> kernel-irqchip would be interpreted as a machine type?
I don't understand this one, I'm afraid.
I mean that "-M pc -M usb" is parsed as "-machine type=pc -machine type=usb" and then merged into "-machine type=usb". The user would expect "-machine type=c -machine usb=on" since "-M pc -M usb=on" works. So "usb=on" cannot always be shortened to "usb", which is surprising. I think this one only affects -M though.