Bus1: Interprozesskommunikation für den Linux-Kernel
Der erste Anlauf mit Kdbus ist gescheitert. Jetzt versuchen die Entwickler aus dem Umkreis von Systemd mit verändertem Konzept erneut Interprozesskommunikation für den Kernel vorzuschlagen. Auf dem anstehenden Kernel-Summit und der zweiten Systemd-Konferenz im Herbst wollen sie das Konzept mit der Kernel-Gemeinde diskutieren.
Der Begriff Interprozesskommunikation, kurz IPC, beschreibt anschaulich, worum es geht. IPC meint die Kommunikation zwischen Prozessen auf einem Computersystem. Unter Linux wird hierzu das im Freedesktop-Projekt entwickelte D-Bus verwendet. Ein Manko der Implementation von D-Bus ist dessen Beschränkung auf den User-Space. Im vergangenen Jahr waren Greg Kroah-Hartman und einige Systemd-Entwickler mit dem Versuch gescheitert, D-Bus in den Kernel zu hieven. Die Gemeinschaft der Kernel-Entwickler war der Meinung, die Fokussierung auf D-Bus bei Kdbus limitiere die Einführung einer optimalen IPC in den Kernel.
Zweiter Versuch einer Kernel-IPC
Jetzt nehmen die Systemd-Entwickler unter Federführung von David Herrmann und Tom Gunderson einen erneuten Anlauf, der weiter gefasst ist als zuvor. Seit rund einem halben Jahr kann die Entwicklung von Bus1 auf GitHub verfolgt werden. Jetzt kündigte Herrmann auf der Mailingliste der Linux Foundation an, den neuen Entwurf auf dem bevorstehenden Kernel Summit Ende Oktober in Santa Fe erstmals vorstellen und diskutieren zu wollen. Auch auf der zweiten Systemd-Konferenz Ende September in Berlin wird Bus1 ein Thema sein. Bus1.ko besteht aus weniger als 5.000 Zeilen Code, ist aber laut Herrmann trotzdem recht komplex und bedingt einigen Erklärungsbedarf, auch hinsichtlich der verwendeten Kernel-Subsysteme.
Anleihen nicht nur bei D-Bus
Der zweite Versuch der Verankerung einer IPC im Kernel stützt sich nicht ausschließlich auf D-Bus, sondern greift Konzepte anderer IPC-Implementationen wie Mach von OS X, Doors von Solaris, Microsofts Midori IPC und vor allem das von Google bei Android genutzte Binder. Anders als das auf Unicast-Nachrichten beschränkte Binder ist Bus1 aber Multicast-fähig. Die Sicherheit soll über das Capabilities-System gewährleistet werden.
Technisch komplex
Neben Capabilities verwendet Bus1 Konzepte wie Handles und File Descriptoren, um die Systemressourcen zu verwalten. Besonderes Augenmerk wird auch auf die Einhaltung der Reihenfolge der zu übermittelnden Nachrichten gelegt. Im Gegensatz zu Binder gibt es in Bus1 keine Überholspur für Nachrichten. Zudem soll Bus1 mit der Anzahl der CPUs skalieren. Das System ist noch nicht fertig, das Feedback auf den anstehenden Konferenzen kann noch Änderungen bewirken. Auf jeden Fall ist der Zeitrahmen für den Versuch einer Implementierung in den Kernel noch nicht absehbar.