[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Maydell
Subject: Re: [PULL 31/31] qemu-option: warn for short-form boolean options
Date: Tue, 16 Feb 2021 14:11:33 +0000

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]