Starting the kdbus discussions

[Lennart Poettering]

On Sun, 29.12.13 13:52, Ted Gould (ted at gould.cx) wrote:

> On Fri, 2013-12-27 at 01:04 +0100, Lennart Poettering wrote:
> 
> > This makes us comfortable to start discussion on the dbus ML regarding
> > the details and what this means for the dbus spec. I have put together a
> > document now that explains what we are doing and how to port a dbus1
> > library over to a kdbus backend. Much of this hopefully should end up in
> > the dbus spec one day.
> > 
> > http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/PORTING-DBUS1
> 
> 
> Glad that you're ready to start talking about this.  I guess the
> question I really want to ask is perhaps the elephant in the room.  With
> a different serialization format, a different name registration scheme,
> different connection parameters, different service description files...
> heck, some of the fields seem arbitrarily inverted.   This doesn't seem
> like DBus at all, but something entirely different, more "DBus inspired"
> rather than something related to DBus itself.

Nope. We provide quite complete compatibility, there are only very few
exceptions visible to app programmers. One is the different policy language
use for the system bus, but even for that we provide full compatbility
if people connect via the good old AF_UNIX protocol.

The flags are no "arbitrarily" inverted. We simply dropped the weird
inversion that dbus1 had there in the first place. Moreover, this is
not visible to the outside anyway, as applications should connect via a
library such as libsystemd-bus, or gdbus to the thing, and those library
trivially abstract the app developer away from this diffrence.

The serialization format is mostly not visible to the outside anyway in
gdbus/libdbus. All the signature logic of GVariant and dbus1 marshalling
is pretty much identical however. In fact, gdbus converts everything
from/to GVariant anyway in userspace already, even on dbus1
marshalling. Morever, we even provide compatibility with dbus1
marshalling, again in the bus proxy. If you complain that gvariant was
so different from dbus1, then you probably shouldn't use glib's gdbus
either.

> Also, it seems that there are rather direct dependencies on systemd.

Both the kernel space side and userspace side are free software. The
activation logic, the bus driver and the compatbility proxy live in the
systemd repo and use systemd apis and technology, that is true. We also
provide an alternative low-level D-Bus client library in systemd
(libsystemd-bus) which can connect to both classic dbus1 and kdbus
directly, and abstracts all differences away.

> While I consider that a negative in itself, it also means that DBus has
> a direct dependency on Linux as I understand that systemd only intends
> to support Linux.  And that seems also a negative for DBus.

Why would it? To applications things look pretty much the same, we
provide the same sockets, and client libraries connecting directly to
kdbus can hide this under the same library interface.

Note in particular that when sockets are used as transport the
unmodified dbus1 marshalling is used. This is extensively used by
systemd to implement things like "systemctl -H" or "systemctl -M" which
allows connections to another host via ssh, or connections to a local
container via namespace-traversing sockets.

> I realize this is a work in progress, but it seems to me that it's not a
> feasible replacement for DBus and in fact something different that is
> intended to work in a more limited set of systems.

Yeah, it might not be an appropriate choice for you/Ubuntu, but I see no
reason why this would even matter to you, given that everybody else can
use this just fine and things are pretty much compatible for app
developers.

Ubuntu is welcome to stay with classic dbus-daemon/dbus1, the APIs
exposed by gdbus and so on abstract the backend away. 

Lennart

-- 
Lennart Poettering, Red Hat