[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v5 0/8] Configurable policy for handling deprecated interface
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v5 0/8] Configurable policy for handling deprecated interfaces |
Date: |
Mon, 21 Sep 2020 16:58:19 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
Peter Maydell <peter.maydell@linaro.org> writes:
> On Mon, 14 Sep 2020 at 09:55, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> New option -compat lets you configure what to do when deprecated
>> interfaces get used. This is intended for testing users of the
>> management interfaces. It is experimental.
>>
>> -compat deprecated-input=<in-policy> configures what to do when
>> deprecated input is received. Available policies:
>>
>> * accept: Accept deprecated commands and arguments (default)
>> * reject: Reject them
>> * crash: Crash
>>
>> -compat deprecated-output=<out-policy> configures what to do when
>> deprecated output is sent. Available output policies:
>>
>> * accept: Emit deprecated command results and events (default)
>> * hide: Suppress them
>>
>> For now, -compat covers only deprecated syntactic aspects of QMP. We
>> may want to extend it to cover semantic aspects, CLI, and experimental
>> features.
>
> Some bikeshedding on option naming...
>
> If this only covers QMP, should we make the argument to -compat
> have a name that expresses that? eg deprecated-qmp-input,
> deprecated-qmp-output ?
It's only implemented for QMP so far. But we really want it for all
external interfaces for use by machines. Today, that's QMP and CLI.
Naming the parameters deprecated-qmp-{input,output} leads to separate
settings for QMP and CLI.
Naming them just deprecated-{input,output} leads to a single set of
settings common to all externeal interfaces, or to sugar for setting all
the deprecated-*-{input,output} we may have.
I don't think getting it wrong now would be a big deal. No excuse for
getting it wrong unthinkingly :)
> Also, it seems a bit repetitive to say 'deprecated' here all
> the time -- do you have a future use of -compat in mind which
> would be to adjust something that is *not* deprecated ? If
> not, maybe the 'deprecated' part should be in the option name
> rather than in every argument, eg
>
> -deprecation-compat qmp-input=crash,qmp-output=hide,cli-option=reject
>
> ?
My cover letter hints at such future uses: "We may want to extend it to
cover [...] experimental features." Something like
-compat experimental-input=reject,experimental-output=hide
- [PATCH v5 8/8] qapi: New -compat deprecated-input=crash, (continued)
- [PATCH v5 8/8] qapi: New -compat deprecated-input=crash, Markus Armbruster, 2020/09/14
- [PATCH v5 7/8] qapi: Implement deprecated-input=reject for QMP command arguments, Markus Armbruster, 2020/09/14
- [PATCH v5 2/8] qapi: Implement deprecated-output=hide for QMP command results, Markus Armbruster, 2020/09/14
- Re: [PATCH v5 0/8] Configurable policy for handling deprecated interfaces, Richard W.M. Jones, 2020/09/21
- Re: [PATCH v5 0/8] Configurable policy for handling deprecated interfaces, Peter Maydell, 2020/09/21
- Re: [PATCH v5 0/8] Configurable policy for handling deprecated interfaces,
Markus Armbruster <=