On Thu, Oct 24, 2019 at 02:34:58PM +0200, Markus Armbruster wrote:
This policy suppresses deprecated events, and thus permits
"testing
the future".
One thing that occurs to me is that this is a fairly passive impact
on libvirt. eg it may well be not at all obvious if libvirt is behaving
in a broken way due to an event not being emitted, as the code in
question simply won't be triggered.
With the current QMP this situation is unavoidable since QEMU doesn't
know which events the client (libvirt) is actually using. QEMU just
unconditionally emits all events.
I've often wondered if we should have the client explicitly tell
QEMU which events it wants to receive as part of the QMP greeting
handshake.
ie, libvirt knows which events it can handle. QEMU knows which
events it can emit, and reports this via capabilities which
libvirt probes.
So on connecting libvirt can tell QEMU exactly which evnets it
wants to get back. QEMU is now able to explicitly tell libvirt
it has asked for a deprecated event, and so the logic from the
"deprecated-input" option can take effect.
We'd not need "deprecated-output" at that point.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|