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: Markus Armbruster
Subject: Re: [PATCH 03/25] qemu-option: warn for short-form boolean options
Date: Wed, 20 Jan 2021 13:59:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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.

Please remember to mention the outlaws in a commit message.

>>> 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?

I concurred with "it's up for discussion".  I'm happy do discuss, of
course.

Delaying reduces (but does not eliminate) the risk of breaking stuff
that uses the sugar.  Is that worth the loss of momentum?  Hard to say.

I think we can ignore non-boolean parameters, because if you're using
the sugar with those, you're kind of begging for some punishment :)

What are the boolean parameters, and is the *any* evidence of use with
the sugar in the wild?




reply via email to

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