[systemd-devel] [HEADSUP] libsystemd-bus + kdbus plans

[Simon McVittie]

On 20/03/13 22:35, Lennart Poettering wrote:
> kdbus is a new kernel implementation of D-Bus that Kay and Greg have
> been working on.

Please talk to the D-Bus maintainers about any reimplementations or
replacements for D-Bus; we are on dbus at lists.freedesktop.org.
(Cross-posted.)

Which parts of the D-Bus Specification does kdbus use?

* I assume it uses the type system and the concepts of object paths and
  bus names, otherwise it'd be a pretty big stretch to call it "D-Bus"
  at all.

* Does it have the same message semantics as traditional D-Bus
  in terms of message headers, senders being unforgeable unique names,
  broadcast/unicast signals, unicast method calls, unicast
  replies/errors, guaranteed delivery, stuff like that?

* Does it have the same ordering guarantees (messages are
  totally-ordered) as D-Bus? If not, what partial-ordering guarantees
  *does* it give? (Causal ordering, perhaps?)

* Does it use the D-Bus message serialization format ("wire format")?

* Does it use the D-Bus SASL handshake?

> d) Port gdbus + classic libdbus.so to become clients for kdbus, too.

How do the other reimplementations of D-Bus (I am aware of at least
ndesk-dbus (C#), dbus-java, haskell-dbus, and Net::DBus (Perl)) interact
with kdbus? For instance, is there a bridge to the traditional D-Bus
wire protocol over Unix/IP/IPv6 stream sockets?

As far as I understand it, in the AF_BUS patchsets, the dbus-daemon
listened on both AF_BUS and stream sockets and bridged messages where
necessary, allowing interoperability without a flag day
(AF_BUS-to-AF_BUS messages bypassed the dbus-daemon entirely, while
AF_BUS-to-stream and stream-to-stream messages continued to pass through
the dbus-daemon). Obviously, anything requiring the performance gains of
a kernel-assisted transport still requires porting, but there doesn't
have to be a flag day.

    S