Starting the kdbus discussions
mzqohf at 0pointer.de
Sun Dec 29 19:55:16 PST 2013
On Mon, 30.12.13 03:15, Alp Toker (alp at nuanti.com) wrote:
> >>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.
> Speaking now as an outsider myself, I think Ted was making an
> observation about the wire protocol rather than developer APIs.
Yeah, we provide the same AF_UNIX protocol as before, under the same
socket path, for compatibility. Of course, it won't take benefit of all
the fancy new kdbus features, but it's compatibility, nothing else after
> >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.
> Perhaps a word diff against the standard D-Bus protocol definition
> will help allay concerns like Ted's, and make sure the various D-Bus
> libraries adopt any tweaks to remain compatible.
This describes the GVariant-based encoding we use on kdbus currently:
Other than that, have a look the the gvariant docs regarding its
I am certainly not going to wdiff this against the bus spec for
you... Note that in the dbus spec we should not document this anyway,
but simply refer to glib's/ryan's spec for the marshalling.
> If I can connect with AF_UNIX and communicate the same way on the
> wire, then it's still D-Bus and I really don't see the problem here.
Yes you can, it's compatbile with that.
Lennart Poettering, Red Hat
More information about the dbus