On Thu, 2023-02-09 at 14:00 +0100, Pierre Morel wrote: > > 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@xxxxxxxxxxxxx> 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? Well, I don't know really, making it unstable is just more conservative for now. But this way you can prototype/implement support in libvirt for topology and then make the interface stable one you've confirmed that everything works as intended. Here is something to think about: The architecture allows rejection of the PTF polarization change request, if a request is currently in process. A possible design to allow the same semantics for qemu/libvirt would be to set a polarization_change_in_progess bit when a PTF request occurs and refuse subsequent requests until this bit was reset via qmp. This wouldn't result in the event data structure being changed, but its semantics, since it isn't fired for every request anymore. > > Regards, > Pierre >
