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

[Paolo Bonzini]

On 20/01/21 09:42, Markus Armbruster wrote:
> The alternative is to *outlaw* parameters "help" and "?" in QemuOpts.
> I'd be cool with that. >
> > My solution would be to deprecate the QMP "change vnc" command, and
> > postpone switching -vnc to qemu_opts_parse_noisily to 6.2.
>
> QMP command 'change' was deprecated long ago, in 2.5.0 (commit
> 24fb41330, in 2015).  This predated appendix "Deprecated features"
> (which has since become docs/system/deprecated.rst), and remained
> missing there until I corrected it in commit 6d570ca10 (v4.2.0).

Removal patch coming then, together with switching vnc_parse to 
qemu_opts_parse_noisily.

That would restrict qemu_opts_parse to tests, and implicitly outlaw 
parameters "help" and "?".  The other problem would be solved, albeit a 
bit indirectly.

> > 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.
>
> Understand.
>
> > [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.
>
> Concur.

Verbose please. :)  Do you think we should delay the conversion of 
-M/-accel/-object to keyval until 6.2?

Paolo