Daniel P. Berrangé <berrange@xxxxxxxxxx> writes: > 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. Intented use of -compat deprecated-input=error,deprecated-output=hide is "testing the future": make QEMU behave as if the deprecated features were already gone. Can be useful when you want to test code that deals with the anticipated future *now*. It can also be used to ferret out unknown uses of deprecated interfaces: run test suite with it, see what fails. But as you note, the deprecated-output=hide part is somewhat problematic in that role. > 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. QEMU already reports its events via introspection. What's missing is an event subscription mechanism. Should be feasible. Additional benefit: can reduce I/O. > We'd not need "deprecated-output" at that point. If deprecated-input=error makes subscribing to a deprecated event fail, we don't need deprecated-output=hide for events. But events are not the only output: there's also command returns. Consider query-cpus-fast. Returns list of CpuInfoFast. CpuInfoFast member @arch is deprecated. deprecated-output=hide should hide it, except it's not implemented in this series. This is also "a fairly passive impact on libvirt", I'm afraid. We have some 40 events, and having libvirt subscribe to the ones it actually uses is obviously practical. I doubt the subscription idea scales up to return values. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
