D-Bus in the kernel [linux.conf.au 2014]

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 stream 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.
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 will 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.
lca2014.linux.org.au/schedule/...
slides: 0pointer.de/public/lca.pdf

[@edgeeffect]

I don't see why you should use XML... at all! ;)

[@yoinktastic]

While I've never had problems with PulseAudio and SystemD hasn't fucked me over too badly (I'm looking at you binary log format), I really don't see the need to have this in the Kernel. If it's just an IPC for the Kernel with a DBus flavored userland interface that may be ok. I just don't want DBus stability in my Kernel. Then again this may open up the possibility for micro-kernel-ish characteristics. I'm not convinced we need it though.

[@jeschinstad]

Would this also be used by the kernel itself, so that for instance inotify would broadcast?

[@alexsmith2632]

wow, those "most new os" listed are all microkernel or mixed ones

[@LinkerMLin]

感觉对稳定性有冲击

[@alexsmith2632]

Linker Lin 东西加得越多 当然越容易出问题

[@thuc8612]

Can someone tell me how longest delay which I could get if using DBUS( system, per to per) ? I have issue that log print out between sender and reciver is more than 1 second. I don't belive that's is trully dbus delay in bad case, it could be threads in receiver and sender has issue but I can't find out any SPEC talk about delay time using DBUS. Thanks

[@csebastian3]

I just realized that Lennart Poettering is just Elon Musk with glasses on.

[@xmonads]

putting more stuff into the kernel means more bugs, the kernel is already full of shit right now

[@sveu3pm]

wtf is IPC.

[@shubitoxX]

en.m.wikipedia.org/wiki/Inter-process_communication