Hi On Tue, Sep 22, 2020 at 7:39 PM Markus Armbruster <arm...@redhat.com> wrote:
> Marc-André Lureau <marcandre.lur...@redhat.com> writes: > > > Hi > > > > On Mon, Sep 21, 2020 at 1:16 PM Markus Armbruster <arm...@redhat.com> > wrote: > >> > >> marcandre.lur...@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. > > [...] > > > At least, this little D-Bus experiment puts some light on one of the current QMP weakness: it's hard to bind QMP. There are good reasons to prefer strongly typed languages. Whenever QMP is statically bound there, and such changes are made, it is pushing the versionning issues to others. It's probably one of the reasons why people are stuck binding QMP manually: doing it automatically would not be practical, as it would regularly break the interface & build. You have to version the schema & interface yourself. So we end up with multiple bindings, manually bound with mistakes etc. What does this freedom really gives us in exchange? We don't want to commit to a stable API? It's not rocket science, everybody else does it with interface version numbers. What makes QEMU/QMP so different? As for this D-Bus binding, if we don't commit to some better QMP stability guarantees, we could simply bump the version of the D-Bus interfaces for each Qemu release (without compatibility with older versions). It's not a great idea, but it's the best to do then. -- Marc-André Lureau
