Rust-Sabotage im Linux-Kernel durch einen Entwickler?
Ein Programmierer torpediert die Idee, Linux-Treiber in Rust zu schreiben. Eine Lösung des Zanks ist nicht in Sicht, aber wohl nur eine Frage der Zeit.
(Bild: Erstellt mit KI in Bing Designer durch heise online / dmk)
Ein Maintainer des Linux-Kernels hat kürzlich die Aufnahme von Rust-Code in seinem Hoheitsgebiet abgelehnt, das für viele Treiber unerlässlich ist – und damit augenscheinlich die Bestrebungen zum Scheitern verurteilt, Rust zukünftig zur Programmierung von mehr als nur simplen Linux-Treibern nutzen zu können. Einen solchen Eindruck erwecken zumindest gerade zahlreiche Berichte auf Linux-Nachrichtenseiten sowie Aussagen in Foren oder bei Social-Media-Plattformen.
Dabei fallen zwei Sachen meist unter den Tisch: Solches Geplänkel gibt es bei der Linux-Entwicklung häufiger – und zumeist finden sich früher als später Lösungen, mit denen alle Beteiligten – notfalls unter Zähneknirschen – leben können. Das ist auch hier zu erwarten. Dafür dürfte schon die Rückendeckung sorgen, die die zahlreichen zentralen und alteingesessenen Kernel-Entwickler den Rust-for-Linux-Bestrebungen verleihen – Torvalds eingeschlossen.
Blockade beim Code fĂĽr eine essenzielle Technik
Auslöser der aktuellen Aufregung sind Statements des Maintainers vom DMA-Mapping-Helper-Code von Linux, Christoph Hellwig: Er hat die Aufnahme von Änderungen zurückgewiesen, um Direct Memory Access (DMA) bei in Rust geschriebenen Treibern zu nutzen – eine für ordentliche Performance schon seit Jahrzehnten vielfach essenzielle Technik, die dem Prozessor erheblich Arbeit erspart. Hellwig forderte Entwickler auf, den Code stattdessen direkt in Rust-Treibern zu integrieren – das aber erschwert die Wartung für andere Entwickler und widerspricht modernen Gepflogenheiten zum Codedesign.
Im Verlauf der seit der zweiten Januarwoche laufenden Diskussion betonte Hellwig später, keine Interesse daran zu haben, mit in mehreren Programmiersprachen geschriebenen Code hantieren zu wollen – und erwähnt, dass das für Assembler genauso gelte wie für Rust. Er wies dabei auch den Vorschlag zurück, den DMA-Rust-Code separat abzulegen und von jemand anders zu betreuen; dabei sprach er sich zudem mit sehr harschen Worten dagegen aus, Rust-Code in zentrale Areale des Kernels vordringen zu lassen.
Der Linux-Kernel ist eigentlich nicht ein Projekt, sondern hunderte
Die Diskussion zwischen den Entwicklern ist kürzlich neu entflammt, nachdem LWN darüber berichtet hat. Eine gütige Lösung ist nicht in Sicht. Streitereien wie diese hat es bei der Linux-Entwicklung schon dutzende Male zu anderen Themen gegeben. Kein Wunder, denn was nach außen als ein Kernel gesehen wird, sind eher über hundert Fürstentümer unter der Ägide von Linus Torvalds.
Die Fürsten arbeiten zwar gemeinsam an Größerem, haben aber weitreichende Hoheit über ihren Bereich – eine bei einem Subsystem richtige Codeformatierung, Bug-Meldung oder Patch-Einreichung wird gegebenenfalls bei einem anderen als grundverkehrt abgeschmettert. Naturgemäß sind sich die verschiedenen Subsystem-Maintainer über das große Ganze und die Interaktion der verschiedenen Bereiche zudem immer mal wieder uneinig, was zu Streitereien wie der aktuellen führt.
Videos by heise
Im Zweifel entscheidet Torvalds
Manchmal tricksen die Fürsten dann etwas, um eine Blockade eines anderen Subsystems zu umschiffen. Manchmal klappt das unter Beißholz-Einsatz der Beteiligten, manchmal aber knallt es. Im Zweifel spricht Linus Torvalds früher oder später ein Machtwort – entweder in echt, oder indem er Code gegen den ausdrücklichen Willen eines Maintainers annimmt.
Im dümmsten Fall packt der dann seine Sachen, aber derlei passiert selten. Der letzte größere Konflikt dieser Art war der erweiterbare Prozess-Scheduler, gegen dessen Aufnahme sich die Maintainer des Prozess-Schedulers lange gewehrt hatten – bis Torvalds durchblicken ließ, den Code mittelfristig trotzdem aufzunehmen. Das passierte dann über ein Jahr später bei Linux 6.12.
Ein Auskommen dieser Art ist auch beim aktuellen Konflikt wahrscheinlich. Bis es zu derlei kommt, hält sich Torvalds aber zumeist öffentlich aus Diskussionen raus – kein Wunder also, dass er auf eine Bitte um ein Statement zur Rust-DMA-Sache nicht reagiert hat.
Daher ist es gut möglich, dass der aktuelle Konflikt weiter schwelt, bis ein auf DMA angewiesener und in Rust geschriebener Treiber in den Kernel einfließen soll oder deren Zahl wächst. Erstes könnte aber schon bald der Fall sein: Ein Red-Hat-Entwicker hat gerade erste Teile des in Rust geschriebenen Nova-Grafiktreibers zur Integration eingereicht, der moderne Nvidia-GPUs unterstützt und den Treiber "Nouveau" beerben soll. Für ihn ist DMA unerlässlich.
Subsystem-Betreuer stehen oft schon unter hohem Druck
Vorsicht übrigens bei vorschnellen Einordnungen zu Blockaden wie die des Rust-DMA-Codes: Oft gibt es dafür Gründe, die im Verborgenen liegen. Viele Subsystem-Maintaintainer etwa sind hoffnungslos überarbeitet, weil ihnen ihr Arbeitgeber nur wenig Zeit für die Betreuung des Upstream-Codes einräumen; zudem gibt es auch viele Betreuer, die den Job komplett in der Freizeit machen. Bei Vielen verschwimmen zudem die Grenzen zwischen Arbeitszeit und Freizeitengagement.
Da ist es nur verständlich, wenn sich Maintainer gegen Änderungen wehren, die zu zwischenmenschlichen Problemen führen können, die Wartung verkomplizieren oder das Arbeitspensum ohne gute Gründe weiter erhöhen. Dazu zählt etwa engere Zusammenarbeit mit vielleicht ungeliebten oder unbekannten Entwicklern als Co-Maintainern – oder eben auch Code in einer weiteren Programmiersprache, die der jeweilige Subsystem-Maintainer nicht beherrscht und auch nicht mal eben an einem Abend lernen kann oder will. Zudem kann solcher Code dann auch dafür sorgen, dass angedachte Umbauten unmöglich oder deutlich erschwert werden.
Einblicke in die Streitereien, die anderswo geheim bleiben
Manchmal sind solche Blockaden daher auch nur Hebel, um Problemen mehr Aufmerksamkeit zu verschaffen oder andere Akteure dazu zu bringen, Mittel zur Linderung locker zu machen. Bei der Entwicklung von Kerneln von macOS oder Windows passiert derlei auch, aber halt firmenintern hinter verschlossenen TĂĽren. Aber am Ende gilt hier wie dort: Vieles wird nicht so heiĂź gegessen, wie es zuvor gekocht wurde.
(dmk)
