Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now)

[Markus Armbruster]

Marc-André Lureau <marcandre.lureau@redhat.com> writes:

> Hi
>
> On Mon, Sep 21, 2020 at 1:16 PM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> marcandre.lureau@redhat.com writes:
[...]
>> > Finally, given that the QAPI types are easy to serialize, it was simple
>> > to use "serde" on them, and provide a D-Bus interface for QMP with zbus.
>> > (a similar approach could probably be taken for other protocols, that
>> > could be dynamically loaded... anyone like protobuf better?)
>>
>> QMP is an *external* interface.
>>
>> It supports compatible evolution: we can make certain kinds of changes
>> without affecting clients.  These include:
>>
>> * Adding optional arguments
>>
>> * Adding results
>>
>> * Adding values to an enumeration type, branches to a union or
>>   alternate
>>
>> * Reordering members of enumerations, structs, unions
>>
>> * Turning an argument type into an alternate with the old type as branch
>>
>> We've made use of this extensively.  See also
>> docs/devel/qapi-code-gen.txt section "Compatibility considerations."
>>
>> How do such changes affect clients of the proposed D-Bus interface?
>>
>
> It's not just about the D-Bus interface though.
>
> QMP being JSON, being lazily typed: everytime we make such changes, we
> inflict some pain to all the QMP bindings that want to have a
> statically checked & native version of the interface. Iow, we should
> think twice before doing any of this.

Having to think twice before doing something we need to do all the time
would slow us down.  I don't think this is going to fly.

QMP is designed to avoid tight coupling of server (i.e. QEMU) and
client.  In particular, we don't want "you have to upgrade both in
lockstep".

A well-behaved client works fine even when it's written for a somewhat
older or newer QMP than the server provides.  "Somewhat" because we
deprecate and eventually remove stuff.  Graceful degradation when the
gap gets too large.

There's a gap between the "lose" wire format, and a "tight" statically
typed internal interface.  The gap exists in QEMU, and we bridge it.
Clients can do the same.  Libvirt does: it provides a statically typed
version of the interface without undue coupling.

Replacing the "lose" wire format by something "tighter" like D-Bus
shrinks the gap.  Good.  It also tightens the coupling.  Bad.

[...]