Re: [PATCH for-6.0 6/6] qapi: Deprecate 'query-kvm'

On Mon, Nov 30, 2020 at 10:21:08 +0100, Markus Armbruster wrote: > Peter Krempa <pkrempa(a)redhat.com&gt; writes: > > > On Fri, Nov 27, 2020 at 16:44:05 +0100, Markus Armbruster wrote: > >> Peter Krempa <pkrempa(a)redhat.com&gt; writes: [...] > > I know it's hard to enforce, but probably the cheapest in terms of > > drawbacks any other solution would be. > > We can and should try. > > Can we flag problematic interface changes automatically? Semantic > changes, no. What about changes visible in query-qmp-schema? I don't know the internals of qemu good enough, but from the perspective of an user of 'query-qmp-schema' it might be possible but not without additional tooling. The output of query-qmp-schema is basically unreviewable when we are updating it. A small change in the schema may trigger a re-numbering of the internal type names so the result is a giant messy piece of JSON where it's impossible to differentiate changes from churn.

I've played with generating/expanding all the possibilites and thus stripping the internal numbering for a tool which would simplify writing the query strings (a libvirtism for querying whether the QMP schema has something [1]). This tool could be used in this case to generate a fully expanded and sorted list which should in most cases be append only when new stuff is added. This could be then used to see whether something changed when we'd store the output and compare it against the new one.

Unfortunately that would just make query-qmp-schema dumps more reviewable in libvirt though. A change in an interface would be noticed only after it hits qemu upstream.

[1] https://gitlab.com/libvirt/libvirt/-/blob/08ae9e5f40f8bae0c3cf48f84181884... https://gitlab.com/libvirt/libvirt/-/blob/08ae9e5f40f8bae0c3cf48f84181884...