qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [PATCH] PoC: Rust binding for QAPI (qemu-ga only, for now)
Date: Thu, 24 Sep 2020 09:31:29 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

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

[...]
> 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?

It's not rocket science, and we're so used to it that we don't even
notice anymore how awful it is.

When you compile to native code, exact interface match is required for
efficiency.

This used to be pretty much a non-issue: when you compile and link
statically, the only interface remaining at run time is system calls.

Dynamic linking threw us into DLL hell.  Yes, we figured out how to
version symbols, when to bump sonames, and how prepare for and make
binary compatible interface changes.  It's still awful.  People deploy
in containers just to get out of this awful game.  But remember: there's
a *reason*, namely efficiency.

Once you go beyond a single process, you need interprocess
communication.  We use procedure calls for intraprocess communication,
so remote procedure calls are an obvious solution for interprocess
communication.

Where many RPC systems have gone wrong, in my opinion, is bringing along
the awfulness of exact interface matches, with much less of a reason,
but even more awfulness: you now get to also wrestle with multiple
versions of servers fighting over ports and such.

Yes, containers, I know.  They help a lot with keeping such messes under
control.  But some messes are necessary, while others are not.

I respectfully disagree with the notion that "everybody else does it
with interface version numbers".  There's a ton of IPC protocols out
there that do not require exact interface matches.

[...]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]