Brussels / 1 & 2 February 2014


Anatomy of kdbus

With kdbus we move the D-Bus IPC system into the Linux kernel to improve performance and functionality while keeping compatibility.

Most more modern OS designs than Unix started out with a high-level IPC from the beginning, and then built the rest of the OS on top of it. Linux/Unix began with only the most basic low-level IPC primitives in place (Pipes and AF_UNIX sockets). Building on those over time various higher-level IPC systems were built, but only very few stood the test of time or became universal. On current Linux systems the best established high-level IPC layer is D-Bus. It implements a reliable message passing scheme, with access control, multicasting, filtering, introspection and supports a flexible object model.

D-Bus is a powerful design. However, being mostly a userspace solution its latency and throughput are not ideal. A full transaction consisting of method call and method reply requires 10 (!) copy operations for the messages passed. It is only useful for transfer of control messages, and not capable of streaming larger amounts of data.

In this talk I'd like to discuss the "kdbus" IPC system, a kernel implementation of the D-Bus logic and its userspace side. "kdbus" takes the concepts of classic D-Bus but makes them more universally useful, reducing latency and roundtrips, and increasing bandwidth, even covering streaming usecases. (For comparison, with kdbus, a full transaction takes only 2 copy operations, even supporting zero-copy for large messages). I'll discuss the lessons we learnt from Android's binder, Solaris' doors IPC system, and Mach's port scheme. We'll discuss how we implemented a reliable (though probabilistic) multicasting scheme, and the tricks we used in userspace to make transparent zero-copy work, without compromising on security, and providing compatibility with classic D-Bus.

kdbus might soon show up in your favourite distribution as part of the systemd package, please attend if you want to know more about the ideas behind it.


Lennart Poettering