Fabiano Rosas <[email protected]> writes:
> Option parameters without a value (i.e. key vs. key=val) are
> deprecated. The missing value is currently implied to be either "on"
> or "off" depending on whether the parameter name starts with "no".
Commit ccd3b3b811 (qemu-option: warn for short-form boolean options,
2020-11-09). Six years of warnings should suffice.
> Remove the implied behavior and start rejecting option parameters
> without values by emitting the error message:
>
> "Parameter 'foo' without a value."
>
> Two special cases remain:
>
> 1) The 'help' parameter is special and still supported. Keep a
> positive value attached to it ("on").
>
> Note that currently there is no validation for the value (if any)
> attached to the help parameter. help, help=on, help=off, help=foo
> all result in the help text being emitted. This is not changed by
> this patch.
Really?
$ qemu-system-x86_64 -chardev help=foo
qemu-system-x86_64: -chardev help=foo: Invalid parameter 'help'
> 2) The empty value is allowed if the key is also empty. This can be
> achieved in the command line by adding commas.
> E.g.: share=on,, is parsed as:
> key:"share" value:"on" and
> key:"" value:"on"
I don't think so:
$ qemu-system-x86_64 -object memory-backend-ram,id=mem0,share=on,,
qemu-system-x86_64: -object memory-backend-ram,id=mem0,share=on,,:
Parameter 'share' expects 'on' or 'off'
Set a breakpoint on qapi_bool_parse() to see the actual value. It's
"on,". In QemuOpts syntax, double comma is an escape, so you can put
comma in values.
> One effect of this change that might not be obvious is that parameter
> combinations of the form:
>
> id=mem0,share,help
>
> no longer produce the help output. The lack of value for the 'share'
> parameter is reported with precedence. Users will need to either use a
> valid value or omit the parameter entirely:
>
> id=mem0,share=on,help
> id=mem0,help
That's unfortunate.
[...]
