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