On 06/28/2018 01:55 AM, Markus Armbruster wrote:
Changing an existing event from broadcast to unicast is an observable
change in existing behavior. Compatibility break unless we can show
nobody can use / uses the observation.
And no one could have been relying on the broadcast COMMAND_DROPPED
event semantics, since OOB was previously experimental and since we just
proved that they are wrong if not limited to one monitor.
Creating a new event is not a compatibility break by itself[*],
regardless of broadcast vs. unicast.
My current plan is that I can touch up scripts/qapi/events.py and
related stuff to allow QMPEventFuncEmit to take a monitor parameter,
then we pass in NULL when we want to send the event to all monitors.
Would that work?
Think so.
Alternatively, a pair of functions:
void qapi_event_bcast_EVENT(... event params ..., Error **errp);
void qapi_event_send_EVENT(Monitor *mon, ... event params ..., Error
**errp);
Slightly more compact in the broadcast case, might be a bit easier to
read.
Also, fewer NULL arguments to add into existing call sites (although
existing call sites would change to use the _bcast_ form, so you're
already touching all call sites, which brings back the topic from the
other mail on dropping useless errp while at it).
[*] In the case of COMMAND_DROPPED, the compatibility break is dropping
commands (the event's trigger), caused by the command queuing feature.
That's why command queuing has to be opt-in. Details discussed
elsewhere in this thread.
Indeed, and I thought the conclusion there was that we DO promise that
COMMAND_DROPPED (and dropped commands in general) won't happen unless
you negotiate oob at initial connection.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
