D-Bus in the kernel
D-Bus has method calls, signals, properties, OO concepts, broadcasting, discovery and introspection, access policy and security, lazy activation, type-safe marshalling, monitoring. It can also pass credentials (limited), file descriptors, …. However, it’s slow (high latency, many copies, many duplicate validations, many context switches). Therefore, it doesn’t work for streams or large payloads. It also has a couple of other limitations.
By moving it to the kernel, the limitations can be overcome: zero-copy broadcast is possible, only one validation and one context switch needed for a single-direction message. There are a lot more possibilities for passing credentials – the receiver requests to see a number of fields on each received message (e.g. timestamp, SELinux context, …). The kdbus will be available at early boot already, so it can really be used by the init system.
For network transparency, the kernel talks the D-Bus network protocol to either a kdbus or a traditional dbus on another machine.
kdbus is a /dev/kdbus node. You mmap receiver buffers on it; when someone sends something, it is copied into your receiver buffer – i.e. it is even less copies than classic sockets. memfds (a new concept that can be used independently of kdbus) are a bit like unlinked files in /tmp, but in addition it can be sealed: after that, it is no longer possible to write to it or modify it – so the receiver can read it and trust it and doesn’t need to copy before validating. The kdbus client library uses memfds to do zerocopy message passing – but only below 512K, because smaller blocks are more efficient to just copy (because mmapping requires rewriting TLBs and that is just slow).
For broadcasting, bloom filters are used to quickly find out who the receivers are.
Kernel code is in kdbus git, the userspace part is in the systemd git. libdbus will include kdbus backend support, so for libdbus users the move will be transparent. There is also a proxy service that fakes to be a dbus-daemon.