qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 03/25] qemu-option: warn for short-form boolean options


From: Paolo Bonzini
Subject: Re: [PATCH 03/25] qemu-option: warn for short-form boolean options
Date: Tue, 19 Jan 2021 18:04:35 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]