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

[Paolo Bonzini]

On 16/02/21 14:36, Peter Maydell wrote:
> > My first submission of this patch even special cased "-chardev" to hide
> > the warning, but this was dropped in response to reviews.
> > (https://patchew.org/QEMU/20201103151452.416784-1-pbonzini@redhat.com/20201103151452.416784-5-pbonzini@redhat.com/).
> >    I can add that back if you prefer, since it's very simple.
> I agree with Daniel that it would be better to be consistent about
> whether we like these short options or not, but disagree that
> the answer is to deprecate everywhere:-)
>
> 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). 
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

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'"

3) one is not be able to specify "-M pc" -M usb" because the second 
kernel-irqchip would be interpreted as a machine type?

Thanks,

Paolo