Il mar 16 feb 2021, 15:11 Peter Maydell <peter.maydell@linaro.org> ha
scritto:

> On Tue, 16 Feb 2021 at 13:44, Paolo Bonzini <pbonzini@redhat.com> 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.

Paolo


> -- PMM
>
>