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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
