News Bus1: Interprozesskommunikation für den Linux-Kernel

[fethomm]

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.

Zur News: Bus1: Interprozesskommunikation für den Linux-Kernel

 

[Miuwa]

Mal für Leute, die nicht so mit dem Linux Kernel vertraut sind: Irgendeine Form von IPC muss er doch anbieten sonst würde DBus ja nicht funktionieren. Was fehlt bei diesem Mechanismus und ließe sich der nicht entsprechen erweitern um als generischer kernel server für beliebige Userspace-IPC Mechanismen zu dienen?

 

[0xffffffff]

Bei "systemd" schrillen bei mir die Alarmglocken. Gibt es bei IPC unter Linux wirklich Bedarf für ein neues System? Mir scheint es so als suchen die systemd Leute dauernd nach Problemen für ihre "Lösungen".

 

[fethomm]

Meines Wissens ist D-Bus eine reine Userspace-Implementierung. Das einzige, was vom Kernel dafür zur Verfügung wird, sind Namensräume. Kdbus war ja der Versuch, diesen vorhandenen Nachrichtenbus in den Kernel zu verlagern. Das wurde aus Sicherheitsgründen und wegen nicht optimaler Geschwindigkeit nicht angenommen. Jetzt gibt es halt einen Capability-basierten erweiterten Vorschlag.

 

[think->write!]

Weshalb der unleserliche Bandwurmsatz, wäres es nicht schöner lesbarer IPC zu schreiben im Titel und es dem Subtitel für unwissende zu lassen was für eine IPC gemeint ist?

 

[mensch183]

Meines Wissens ist D-Bus eine reine Userspace-Implementierung. Das einzige, was vom Kernel dafür zur Verfügung wird, sind Namensräume.

Kaum, da man mit Namensräumen allein keine Daten von Prozess A nach Prozess B schaufeln kann. Irgendein IPC-Mechanismus muß also bei D-Bus involviert sein und dabei muß der Kernel helfen - und seien es temporäre Files(für die der Kernel open/read/write/stat/close macht). Auf meinem Rechner hier enthüllt netstat -a, dass der D-Bus-Kram aktuell Unix domain sockets als IPC verwendet. Hat man die nicht, kann libdbus laut Doku auch TCP sockets nutzen.

Bei "systemd" schrillen bei mir die Alarmglocken. Gibt es bei IPC unter Linux wirklich Bedarf für ein neues System? Mir scheint es so als suchen die systemd Leute dauernd nach Problemen für ihre "Lösungen".

Eine Alternative für die archaischen IPC-Möglichkeiten von Linux wäre schon prima. Aber wenn schon neues IPC, wollen die Linuxer gern was "fetziges", also insb. universelles + effektives haben, was nicht nach 5 Jahren schon wieder obsolet wird, wenn die nächste IPC-Sau durchs Dorf getrieben wird. Im akademischen Bereich sind gefühlt hunderte alternative IPC-Mechanismen erfunden und implementiert wurden, die jeweils irgendetwas sehr gut können. Da muss man sich einen Überblick verschaffen, Rosinenpicken und weise entscheiden, was man in Linux einbauen sollte.

Mit deiner Skepsis gegenüber dem Systemd-Lager bist du sicher nicht allein. Die Ablehnung von kdbus zeigt aber, dass beim Kernel deren Überrumpelungstaktik ("Der Code ist fertig. Das Ding tut irgendetwas nützliches. Das Ding ist ab heute Standard.") nicht reicht, um neue Konzepte an Stellen zu etablieren, die auch andere Leute betreffen.