D-Bus Versus Varlink

[Thomas Kluyver]

I'm struggling to figure out how much varlink is actually used in the wild. Red Hat seem to be involved in it, and things they work on usually show up in Fedora pretty quickly, but there are no varlink libraries or tools installed by default, and the varlink resolver doesn't seem to be running. Podman (another project with RH involved) seems to have thought in 2020 [1] that varlink is more or less deprecated and ripped it out.

On the other hand, systemd seems to be adopting varlink more in the last few months - including creating its own 'varlinkctl' CLI [2] - but I haven't found any overall explanation of why, or what the long-term plan is, just PRs working on varlink support.

It looks like various design choices allow for a convenient CLI, which is something I've always found a bit awkward with D-Bus. Compare these two calls querying the default resolver/bus:

varlink call org.varlink.resolver.GetInfo
dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Basing the protocol on JSON makes it very approachable, especially for all of us who are most used to languages like Python, Ruby or JS.

[1] https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice.html
[2] https://github.com/systemd/systemd/pull/29325

Thomas

On Thu, 21 Mar 2024, at 03:23, Lawrence D'Oliveiro wrote:
> I recently discovered the existence of Varlink <https://varlink.org/>.
> Turns out it’s been around for a few years--here
> <https://lwn.net/Articles/742675/> is some discussion of a rationale for
> its creation. Note this bit:
>
>     ... it aims to provide IPC from early boot onward, though it does
>     not really address the longtime D-Bus performance complaints that
>     also served as motivation for kdbus and bus1.
>
> Commonalities with D-Bus:
> * the concept of an “interface”, uniquely named according to the common
>   reverse-domain format; which (among other things) defines named
>   “methods”, each of which takes zero or more arguments
>   (“in-parameters”) of specified types, and returns zero or more
>   results (“out-parameters”) of specified types.
> * A standardized introspection interface, that can be used to query a
>   connection peer as to what interfaces it supports, and how they are
>   defined.
>
> Differences from D-Bus:
> * No concept of an object path as the target of a method call. Hence no
>   standardized interfaces for managing such objects, no get/set
>   properties etc.
> * No “signals” as such; however, method calls can return no reply, or
>   even multiple replies. They can also return an “error” message
>   indicating something went wrong with the method call.
> * Point-to-point protocol, no intermediary daemon. So a client has to
>   know the address (Unix socket, TCP etc) to connect to.
> * Messages are JSON structs with standardized top-level fields;
>   messages are terminated by a null byte.
> * Struct field/argument types may be marked as “optional”, which means
>   that the value is allowed to be null.
> * Allows user-defined enumeration types, with specified strings as
>   values.
> * Allows user-defined names for enumeration and struct types.
> * Defines its own introspection language, not based on XML (or JSON,
>   or anything else immediately recognizable.)
>
> (Anything else I missed?)
>
> Note that a struct definition has exactly the same syntax as the
> argument lists for methods and errors. Interesting that, instead of
> C-style “«type» «name»” ordering for field/argument definitions, they
> opted for Pascal-style “«name» : «type»” syntax. Named types are also
> defined as “type «name» «definition»”, not as C would have it “typedef
> «definition» «name»”.