|
From: | Paolo Bonzini |
Subject: | Re: [PULL 31/31] qemu-option: warn for short-form boolean options |
Date: | Tue, 16 Feb 2021 14:43:53 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |