[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] qapi: Stop abusing "special" values for so
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-block] [Qemu-devel] qapi: Stop abusing "special" values for something entirely different |
Date: |
Tue, 18 Jul 2017 17:42:30 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Eric Blake <address@hidden> writes:
> On 07/14/2017 12:12 PM, Markus Armbruster wrote:
>>
>> Instead of the last part, I prefer either
>>
>> * so we add a *new* value, such as JSON null.
>
> I like that idea.
>
>>
>> 1. Stop abusing values the schema accepts, but are invalid to mean "do
>> something else entirely".
>>
>> 2. Add a first class null type to QAPI.
>>
>> 3. Turn MigrationParameters members tls-creds and tls-hostname into
>> alternate of str and null. Deprecate "".
>>
>> 4. Add a null member to alternate BlockdefRef. Deprecate "".
>
> Back-compat concerns: would we still accept "" in place of null for a
> release or two?
Yes.
> Is it time to figure out how to add deprecation
> notices/events to QMP?
Yes, getting that in the next development cycle would be nice.
> Or would this be a clean break-over point (since
> introspection exists), where if introspection shows there is an
> alternate between string and null, then libvirt MUST use null instead of
> "" to get the desired semantics?
Feels unnecessarily harsh to me.
>> I got patches for 2., and I intend to work on 3. and 4.
>>
>> Since this is "only" about "less than general and ugly", we may decide
>> to leave things as they are if my patches turn out even uglier.
>>
>> Meanwhile, opinions?
>
> Not much time left for soft freeze (which kind of echoes the dilemma we
> had at 2.9). Is this something you are aiming for in 2.10, or will it
> be all the harder to worry about back-compat (because we'll have two
> releases rather than one before we introduce the alternate-with-null
> semantics)?
Let's try to get it into 2.10.