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

[Markus Armbruster]

Peter Krempa <pkrempa at redhat.com> writes:

> On Mon, Nov 30, 2020 at 10:21:08 +0100, Markus Armbruster wrote:
>> Peter Krempa <pkrempa at redhat.com> writes:
>> 
>> > On Fri, Nov 27, 2020 at 16:44:05 +0100, Markus Armbruster wrote:
>> >> Peter Krempa <pkrempa at redhat.com> 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.

A structural comparison could fare better.

qapi-gen option -u might help:

  -u, --unmask-non-abi-names
                        expose non-ABI names in introspection

> 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.

Such an expansion is one way to compare structurally.  It reports
differences for "command C, argument A.B...".  Mapping to the QAPI
schema is straightforward.

> 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.

Yes, implementing the comparison in the QEMU repository would be more
useful.

> [1] https://gitlab.com/libvirt/libvirt/-/blob/08ae9e5f40f8bae0c3cf48f84181884ddd310fa0/src/qemu/qemu_qapi.c#L392
>     https://gitlab.com/libvirt/libvirt/-/blob/08ae9e5f40f8bae0c3cf48f84181884ddd310fa0/src/qemu/qemu_capabilities.c#L1512