Re: [PULL 31/31] qemu-option: warn for short-form boolean options

[Peter Maydell]

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.

> Likewise for "usb", where the default even depends on the machine type.
>
> 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).

> 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. (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.

-- PMM