- Rust-Code, der die Direct Memory Access API implementiert, wurde als Pull Request in das Linux-Kernel-Repository eingereicht.
- Christoph Hellwig, ein Maintainer im Linux-Kernel, lehnte den Code ab und erklärte, dass Rust-Code nicht in den Linux-Kernel aufgenommen werden solle, womit der Streit begann.
- Als der Konflikt immer größer wurde, verglich Christoph Hellwig Rust mit Krebszellen.
- Hector Martin, der Hauptverantwortliche von Asahi Linux, reagierte verärgert auf diese Äußerung und griff Linus Torvalds in sozialen Medien auf, während er scharfe Kritik äußerte.
- Linus Torvalds warnte Hector Martin mit den Worten „Das Problem bist du selbst“ und forderte ihn auf, „kein Brigading in sozialen Medien zu betreiben“.
- Derzeit hat Hector Martin darum gebeten, von seiner Rolle als Maintainer des Upstream-Linux-Codes für Apple-Arm-kompatible Hardware zurückzutreten.
28 Kommentare
Die Zusammenfassung erwähnt nur die tatsächlichen Ereignisse, aber am Ende des Originaltexts (auf Koreanisch) sind noch zwei zusätzliche Hintergrundinformationen angehängt, die helfen, den Vorfall besser zu verstehen.
Ich halte es zwar für sinnvoll, ein Projekt in einer einzigen Sprache zu verwalten, aber unabhängig davon ist die Art, wie man Kollegen davon überzeugen will, wirklich miserabel.
Jemanden durch Macht in die Knie zu zwingen, ist absurd.
Hier ist der PR-Mail-Thread:
https://lwn.net/ml/all/…
Anscheinend wurde dabei weder die DMA-Implementierung geändert noch direkt an der DMA-API selbst Hand angelegt, sondern es handelt sich um einen PR, der FFI-Bindings schreibt, damit man aus Rust auf die DMA-API zugreifen kann.
Ein solcher PR wurde dann mit der knappen Antwort „No rust code in kernel/dma, please.“ abgelehnt, https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
Und auf die Frage, wie man es stattdessen machen solle, kam dann „Keep the wrappers in your code instead of making life painful for others.“ https://lwn.net/ml/all/20250108151858.GB24499@lst.de/
(Das wurde tatsächlich genau so gemacht. Der PR ändert nicht
kernel/dma, sondern den Unterbaumrust/kernel.)Natürlich entsteht durch zusätzliche FFI-Bindings die Belastung, dass bei Änderungen an der DMA-API auch die Rust-FFI-Bindings angepasst werden müssen,
aber selbst obwohl von der Rust-Seite gesagt wurde, dass man sich darum schon kümmern werde, bin ich mir nicht sicher, ob es richtig ist, dass sich jemand, der nicht für diesen Baum zuständig ist, in dieser Haltung so dagegenstellt.
(Christoph Hellwig ist Maintainer von
kernel/dma: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)Deshalb hat Hector Martin Linus wohl in den Thread hineingezogen:
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
Interessant ist aber auch, was direkt im vorangegangenen Thread gesagt wurde:
Wenn es eine breaking change in der API gibt und das Rust-Team nicht schnell genug darauf reagiert, schlägt der Build fehl, und Linus nimmt den PR dann nicht an.
Wenn ich das als Problem zwischen dem Modul betrachte, das die breaking change verursacht hat, und einem anderen Modul, dann scheint mir die Seite mit Rust eher die bessere zu sein.
Es ist also eine Situation, in der Modul x eine breaking change eingeführt hat und Modul y nicht schnell genug reagieren konnte:
Im Linux-Kernel sind die Stellen, an denen Rust
unsafeverwendet, größtenteils die Bereiche, die C wrappen.Daneben gibt es auch Hardware-Steuerungsbereiche, in denen Speicher direkt behandelt werden muss, aber das ist nur ein sehr kleiner Teil.
Der Bereich, in dem Rust eingesetzt wird, ist die Treiberentwicklung. Speicherverwaltung, Block-Layer oder der Kernel selbst müssen nicht angefasst werden und können es auch nicht.
Es gibt weit mehr Treiber-Code als eigentlichen Kernel-Code. Und die Stellen, an denen Probleme auftreten, sind größtenteils ebenfalls im Treiber-Code.
Ich denke, es ist richtig, dass der Bereich der Treiberentwicklung statt in C in einer Sprache mit höherer Speichersicherheit und besserer Sicherheit entwickelt wird.
Ob das nun Rust, Zig oder etwas anderes ist, weiß ich allerdings nicht.
Ich kann auch nachvollziehen, dass Rust für die Entwicklung normaler Anwendungen übermäßig komplex ist und für C-Entwickler schwer schnell zu lernen ist.
Trotzdem hoffe ich, dass wenigstens die Treiberentwicklung, egal in welcher Sprache, auf eine moderne Sprache umgestellt wird.
In meiner früheren Firma habe ich für die Entwicklung und Stabilisierung eines Treibers mit nur ein paar Tausend Zeilen ungefähr 7 Jahre gebraucht; ganz so einfach lässt sich das zwar nicht herunterbrechen, aber grob geschätzt entfielen etwa 3 Jahre allein auf das Debugging.
Die meisten davon waren speicherbezogene Bugs. Logische Fehler wie Deadlocks machten nur einen kleinen Teil aus.
Es wirkt nicht besonders sinnvoll, große Projekte als Experimentierfeld für die eigene Sprache zu benutzen.
Wenn es hart auf hart kommt, sollte man wieder zu früher zurückkehren und forken.
Bei einem Kernel, der die gesamte Gerätebasis abdeckt, kann ich mir bei Rust nur vorstellen, dass der Code spätestens dann schwer lesbar wird, wenn man anfängt,
unsafezu verwenden.Ich verstehe auch nicht, warum man Teile portiert, die bisher gut funktioniert haben – es handelt sich ja nicht um ein Projekt ohne richtige Main-Releases wie 0.91, 0.92, 0.99, 0.991 und so weiter.
Es ist ja auch nicht so, dass man gesagt hätte: Dabei haben wir einen großen Bug behoben und es zugleich sicherer gemacht.
Dieser PR ist kein Port. Es handelt sich um einen PR, der auf der Rust-Seite FFI-Bindings hinzufügt, damit die bestehende DMA-API auch in neu geschriebenen, Rust-basierten Modulen verwendet werden kann. Und genau das wurde vom DMA-Verantwortlichen blockiert.
Schade, dass im Artikel das zitierte Original nicht enthalten ist. Ich war neugierig, habe den Originaltext gesucht und gelesen, und auch wenn ich es selbst nicht ganz vollständig durchdrungen habe, scheint es mir, dass es im Hintergrund deutlich mehr Vorgeschichte gibt, als man es einfach nur so darstellen könnte wie im Original.
Der Titel des Artikels wurde auf den Namen des Originals geändert.
Danke für die Bearbeitung.
Es hat sich wohl doch nicht als so spannend erwiesen, Rust an eine große C-Codebasis anzuflanschen, wie man vielleicht dachte. Wenn es darum geht, die Speichersicherheit zu erhöhen, wird der
unsafe-Bereich am Ende ohnehin größer, sodass der praktische Nutzen nicht besonders groß ist ... Letztlich hat es kaum eine größere Bedeutung, als dass der Einsatzbereich von Rust wächst ... Daher scheint es ein natürlicher Verlauf zu sein, dass dies den Widerstand bestehender C-Entwickler hervorruft. Vielleicht wäre es besser, sich auf ein Kernel-Projekt zu konzentrieren, das wirklich von Anfang an mit Rust startet.Die Qualität des eigentlichen Artikels ist überraschend solide. Hat Spaß gemacht zu lesen.
Die Aussage „Das Problem bist du“, die Torvalds gemacht hat, zielte unabhängig von der Einführung von Rust darauf ab, dass soziale Netzwerke keine Antwort auf technische Probleme sein können; allein diese Zusammenfassung könnte jedoch missverständlich sein.
Für Hector Martin war es letztlich eine unvermeidliche Entscheidung.
Das mittlere Management von Linux ist komplett mit C-Experten besetzt – warum sollten sie schon auf die Meinung der wenigen Rust-Entwickler hören?
https://youtu.be/opTJH76wJxs?si=WHR0_1uPpSlpDTHr zeigt, wie sich die Debatte zuspitzt.
Hat Torvalds Rust nicht auch erlaubt?
Torvalds hat in dieser Debatte kein einziges Wort über Rust verloren.
Wenn es Meinungsverschiedenheiten über technische Fragen gibt, sollte die Diskussion auf technischer Grundlage geführt werden; man sollte nicht versuchen, den Streit zu beenden, indem man in sozialen Netzwerken Stimmung macht.
Wenn ihr so gut seid, dann forkt doch den Kernel und schreibt alles komplett in Rust. Statt euch wie Krebs allmählich hineinzufressen. Solche Meinungen gibt es viele.
Wenn der betreffende Code
kernel/dmageändert hätte, um die Nutzung in Rust zu erleichtern, wäre das eine andere Sache, aber tatsächlich wurde nur eine FFI-Schicht, diekernel/dmakapselt, zurust/kernel/dmahinzugefügt.Der ursprüngliche Code wurde nicht angefasst.
Im Kern geht es in Wirklichkeit eher darum:
"Ich möchte nicht, dass Leute bei mir anklopfen, wenn sie die offizielle DMA-FFI in Rust falsch verwenden." So ungefähr ...
Und dann wurde auch noch widersprüchlich behauptet, man solle die FFI eben einfach auf Ebene der einzelnen Treiber selbst erstellen lassen.
Das ist Redox. Vermutlich geht man deshalb zu Linux, weil es noch Bereiche gibt, die nicht unterstützt werden ...
https://vt.social/@lina/113064510447670892
Was Sie geschrieben haben, scheint vollständig Helwigs Aussagen zu entsprechen, aber ich bin mir nicht sicher, ob man diese Meinung als Mehrheitsmeinung ansehen kann.
Hallo. Vielen Dank, dass Sie diesen guten Beitrag veröffentlicht haben. Ich habe ihn mit Freude gelesen.
Allerdings habe ich den Originaltext überprüft und beim Blick auf dessen Titel ein paar Bedenken bekommen, weshalb ich diesen Kommentar schreibe.
https://news.hada.io/guidelines
> Grundsätzlich bitten wir darum, entweder den Originaltitel zu verwenden oder den Titel ins Koreanische übersetzt zu veröffentlichen.
So wird es dort vorgeschlagen. Und nachdem ich den Inhalt des betreffenden Artikels gelesen habe, denke ich, dass der Titel „Linus Torvalds: ‚Das Problem sind Sie‘“ statt „Die Rust-Debatte im Linux-Kernel flammt erneut auf“ noch eher zu Missverständnissen über den Inhalt des Artikels führen kann als der ursprüngliche Titel.
Vielen Dank nochmals für die Zusammenfassung und die Vorstellung des Artikels. Ich wünsche Ihnen einen schönen Tag.
Spitzenklasse
Ich werde es berücksichtigen.
'm 'b Ich wünsche Ihnen einen schönen Tag! Vielen Dank, dass ich dank Ihnen einen guten Artikel lesen konnte. (__ )
Ich hatte die Angewohnheit, für eine etwas genauere Erklärung dem Titel meinen eigenen Untertitel hinzuzufügen, aber der Titel passte anderen offenbar nicht und ich wusste auch nicht, dass es eine solche Regelung gibt. Ab dem nächsten Mal werde ich ihn so wie im Original wiedergeben.
Während der ursprüngliche Titel sofort erkennen lässt, worum es in dem Beitrag geht, scheint der von Ihnen geänderte Titel potenziell missverständlich und könnte fälschlich als Clickbait aufgefasst werden. Das ist meine persönliche Meinung.
Danke für Ihre Meinung.
Ich hielt Linus’ Aussage für am wichtigsten und habe sie deshalb als Titel verwendet, aber offenbar wurde sie dadurch stark verzerrt.
Ich werde künftig auf jeden Fall vorsichtiger sein.