Re: [PATCH v15 10/11] qapi/s390x/cpu topology: CPU_POLARITY_CHANGE qapi event

[Pierre Morel <pmorel@linux.ibm.com>]

On 2/9/23 13:28, Nina Schoetterl-Glausch wrote:
> On Wed, 2023-02-08 at 20:23 +0100, Markus Armbruster wrote:
>> Nina Schoetterl-Glausch <nsg@linux.ibm.com> writes:
>>

...

> 
>>
>>> I also wonder if you should add 'feature' : [ 'unstable' ].
>>> On the upside, it would mark the event as unstable, but I don't know what the
>>> consequences are exactly.
>>
>> docs/devel/qapi-code-gen.rst:
>>
>>      Special features
>>      ~~~~~~~~~~~~~~~~
>>
>>      Feature "deprecated" marks a command, event, enum value, or struct
>>      member as deprecated.  It is not supported elsewhere so far.
>>      Interfaces so marked may be withdrawn in future releases in accordance
>>      with QEMU's deprecation policy.
>>
>>      Feature "unstable" marks a command, event, enum value, or struct
>>      member as unstable.  It is not supported elsewhere so far.  Interfaces
>>      so marked may be withdrawn or changed incompatibly in future releases.
> 
> Yeah, I saw that, but wasn't aware of -compat, thanks.
> 
>>
>> See also -compat parameters unstable-input, unstable-output, both
>> intended for "testing the future".
>>
>>> Also I guess one can remove qemu events without breaking backwards compatibility,
>>> since they just won't be emitted? Unless I guess you specify that a event must
>>> occur under certain situations and the client waits on it?
>>
>> Events are part of the interface just like command returns are.  Not
>> emitting an event in a situation where it was emitted before can easily
>> break things.  Only when the situation is no longer possible, the event
>> can be removed safely.
> 
> @Pierre, seems it would be a good idea to mark all changes to qmp unstable, not just
> set-cpu-topology, can just remove it later after all.

OK.

Just curious: how do you think this simple event matching the guest 
request 1 on 1 may evolve?

Regards,
Pierre

-- 
Pierre Morel
IBM Lab Boeblingen