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

[Lennart Poettering]

On Mon, 25.03.13 13:06, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> 
> 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.)

Well, the kernel code isn't really there yet, as mentioned. We first
need to figure out what we want precisely, and want to have some code.

> 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")?

Pretty much all of the above, though Ryan wants us to adopt GVariant as
serialization, but this is mostly orthogonal to the transport. The way
we want this to work is that the kernel never actually looks into the
message body, and does filtering only via pre-calculated bloom filters
attached to each message. As long as all client libraries understand all
different serialization methods we can replace the serialization freely.

But anyway, adopting GVariant for this, might make sense (because we
want something 64bit-safe, which the classic dbus serialization is not),
but as mentioned the kernel wouldn't care.

> * Does it use the D-Bus SASL handshake?

No. The kdbus stuff is kernel only, and access is controlled via file
access modes on the device node of the specific bus.

> > 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?

We can do such a bridge (in fact, systemd will ship one anyway, since we
support dbus-via-ssh as a transport to access commands on other
systems). However, these other dbus implementations are not really my
priority, but of course would welcome if they are ported sooner or later.

> 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.

Well, the flag day is mostly regarding the policy stuff. We don't want
to support the current policy in the kernel, and thus we'd require
userspace services to fix their stuff to not really on it first...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.