On 19/01/21 16:56, Markus Armbruster wrote:
+ if (!is_help && warn_on_flag) {
+ warn_report("short-form boolean option '%s%s' deprecated",
prefix, *name);
+ error_printf("Please use %s=%s instead\n", *name, *value);
+ }
If @warn_on_flag, we warn except for "help" and "?". The exception
applies regardless of @help_wanted. Shouldn't we except*only*
recognized help requests?
Suggesting "help=yes" would be worse.
- opts = opts_parse(list, params, permit_abbrev, false,
+ opts = opts_parse(list, params, permit_abbrev, false, true,
opts_accepts_any(list) ? NULL : &help_wanted,
&err);
if (!opts) {
This function now warns, except for "help" and "?". The exception
applies even when we treat "help" and "?" as sugar for "help=on" and
"?=on" because opts_accepts_any().
It is the only spot that enables the warning.
Does all user input flow through qemu_opts_parse_noisily()?
I was going to say yes, but -vnc (and worse, the QMP version of "change
vnc") is parsed by qemu_opts_parse() via ui/vnc.c (besides being used by
lots of tests). -vnc has several boolean options, and though Libvirt
only uses "sasl" it does so in the short form.
My solution would be to deprecate the QMP "change vnc" command, and
postpone switching -vnc to qemu_opts_parse_noisily to 6.2.
The main reason to warn for short-form boolean options, is to block them
for command line options that are switched to keyval[1]. Adding a
warning does not necessarily imply removing in two releases.
Paolo
[1] This series already does that for -M, -accel and -object. This
means that applying this series would change the command line
incompatibly without a two-release deprecation. It's up for discussion
whether to do so, or delay the application of those patches to 6.2. It
would be a pity to hold the dependent changes for effectively a year,
but it's not a big deal.
