Rust-Experiment im Linux-Kernel (erfolgreich) beendet

• Die Integration von Rust in den Linux-Kernel hat die Experimentierphase abgeschlossen und wird als offizieller Bestandteil anerkannt
• Auf dem jährlichen Maintainers Summit einigten sich die Entwickler darauf, die Rust-Unterstützung als dauerhafte Funktion zu übernehmen
• Entsprechend soll das „experimental“-Tag aus dem Rust-bezogenen Code im Kernel entfernt werden
• Ein LWN-Redakteur erklärte: „Das Experiment ist vorbei, und es war ein Erfolg“, und erwähnte dabei die Leistung des Rust-for-Linux-Teams
• Dies gilt als wichtiger Wendepunkt für die Erweiterung der Kernel-Entwicklungssprache sowie für Sicherheit und Modernisierung

---

Ende des Rust-Experiments im Kernel und offizielle Übernahme

• Auf dem jährlichen Maintainers Summit wurde die Rust-Unterstützung im Kernel diskutiert, und die anwesenden Entwickler waren sich einig, dass Rust keine experimentelle Funktion mehr ist
  • Rust ist nun ein fester Kernbestandteil des Kernels
  • Entsprechend soll die „experimental“-Kennzeichnung aus dem betreffenden Code entfernt werden
• Ein LWN-Redakteur schrieb in einem Beitrag ausdrücklich: „Das Experiment ist vorbei, und es war ein Erfolg“
  • Dabei übermittelte er auch Glückwünsche an das Rust-for-Linux-Team

Reaktionen der Community

• Der Titel des Beitrags führte kurzzeitig zu Missverständnissen, sodass einige Leser irrtümlich annahmen, Rust werde entfernt
  • In mehreren Kommentaren hieß es etwa: „Für einen Moment reingelegt“ oder „eine emotionale Achterbahnfahrt“
• Einige Nutzer reagierten mit Humor und verwiesen auf den Headline-Stil von Phoronix
  • Zugleich wurde angemerkt, dass die Benchmark-Aktivitäten und Open-Source-Ökosystem-Updates von Phoronix nützlich seien
• Andere Kommentare erwähnten, dass Microsoft Rust auch im Windows-Kernel einführt
  • Es wurde die Meinung geäußert, dass einige Komponenten bereits in Rust geschrieben seien und bereits in ausgelieferten Versionen enthalten seien

Bedeutung der Rust-Einführung

• Durch die Umwandlung der Rust-Unterstützung im Kernel in eine offizielle und dauerhafte Funktion werden
  stärkere Memory Safety und die Einführung einer modernen Sprache dauerhaft Teil der Kernel-Entwicklung
• Da Rust sowohl im Kernel als auch unter Windows übernommen wird, wird der Generationswechsel bei Systemprogrammiersprachen zunehmend sichtbar
• Die Community sieht diese Entscheidung als Abschluss eines erfolgreichen Experiments und verbindet damit Erwartungen an den weiteren Ausbau von Rust-basierten Kernel-Modulen

[secret3056]

Dafür sind aber nicht mehrere Maintainer abgesprungen?

[bus710]

Es gibt genau ein einziges Buch zu diesem Thema auf Koreanisch, aber leider ist es mit aktuellen Kerneln überhaupt nicht vollständig kompatibel, weil sich die Art und Weise, wie Rust im Linux-Kernel verwendet wird, mehrfach durch Breaking Changes geändert hat. Es wäre wirklich schön, wenn das über GitHub oder Ähnliches ergänzt werden könnte.

[GN⁺]

Hacker-News-Kommentare

• Die Rust-Unterstützung hat sich in den letzten 2 Jahren wirklich stark weiterentwickelt
  Inzwischen kann man Kernel-Module fast ohne Boilerplate schreiben
  Ich finde, dass das Entfernen des „experimental“-Tags ein großer Meilenstein ist
  Der echte Wendepunkt wird wohl der Tag sein, an dem Distributionen Kernel ausliefern, bei denen die Rust-Unterstützung standardmäßig aktiviert ist

  • Einige Distributionen machen das bereits
    Zum Beispiel aktivieren NixOS und Arch den in Rust geschriebenen QR-Code-Kernel-Panic-Bildschirm
    Soweit ich weiß, unterstützt Fedora das vermutlich auch
  • Soweit ich weiß, wird Fedora 43 mit CONFIG_RUST=y kompiliert
  • Ich frage mich, was mit der Formulierung „Kernel mit standardmäßig aktivierter Rust-Unterstützung“ genau gemeint ist
    Das bedeutet ja nicht, dass der Kernel Rust-User-Space unterstützt, sondern nur, dass ein Teil des Kernel-Codes mit rustc kompiliert wird
  • Ich frage mich, ob das auf allen Plattformen möglich sein wird, bevor Rust in GCC vollständig unterstützt wird

• Nach langem Widerstand ist es bewegend, dass Rust im Linux-Kernel nun offiziell übernommen wurde
  Applaus an das Rust-for-Linux-Team

  • Ich erinnere mich daran, dass es früher rund um Rust-Code im Asahi-Projekt durch die Ablehnung von Maintainer-Seite Verwirrung gab
    Ich frage mich, ob dieser Vorfall der erste Dominostein des Projekts war
  • Laut einem Phoronix-Artikel
    ist Alex Gaynor, der Co-Maintainer von Rust for Linux, offiziell zurückgetreten
    Miguel Ojeda ist nun der einzige offizielle Maintainer, dazu kommen mehrere Code-Reviewer

• Ich frage mich, ob das Entfernen des „experimental“-Tags bedeutet, dass nun alle Maintainer verpflichtet sind, Rust-Code nicht kaputtzumachen

  • Tatsächlich ist es nur ein Signal dafür, dass Rust nun fest im Kernel verankert ist
    Es vermittelt Entwicklern die Sicherheit, dass sie in Rust-basierte Treiber investieren können
    Die Regeln bleiben gleich, und Code, der den Rust-Build kaputtmacht, kann nicht an Linus geschickt werden
  • Innerhalb des Kernels ist Stabilität außer bei User-Space-APIs nicht garantiert
    Das heißt, selbst wenn ein Maintainer internen Rust-Code kaputtmacht, ist das kein Regelverstoß

• Ich frage mich, ob Architekturen, die Rust nicht unterstützt, jetzt aufgegeben werden

  • Nein. Rust wird derzeit nur im Treiber-Subsystem verwendet
    Die Kernbestandteile des Kernels müssen weiterhin in C geschrieben werden
  • Ich frage mich, welche Architekturen nicht unterstützt werden
  • Im Scherz hieß es: „Ja, die sind alle cooked“

• Es heißt, der Artikeltitel sei in „The (successful) end of the kernel Rust experiment“ geändert worden
  Grund dafür sei das Feedback der Community gewesen, dass der ursprüngliche Titel übertrieben war

  • Ich halte den geänderten Titel für passend
    Laut den Hacker-News-Richtlinien
    soll man „den ursprünglichen Titel nur ändern, wenn er irreführend ist“
  • Das Wort „successful“ scheint schon impliziert zu sein
    Denn ein gescheitertes Experiment endet nicht auf diese Weise
  • Im Scherz wurde ein Titel wie „Linux devs tried Rust — you won’t BELIEVE the reaction!“ vorgeschlagen

• Auf die Frage „Ist das eine große Sache?“

  • „Ja, es ist eine große Abhängigkeit, die hinzugekommen ist“
  • Ein kurzes „Ja“ als Zustimmung

• Wenn Linux-Kernel-Treiber nun Richtung Rust gehen, frage ich mich, ob BSD-Systeme wie FreeBSD dieselbe Oxidation erleben werden
  Oder ob es Widerstand und eine Abspaltung geben wird

• Ich begrüße neue Versuche

  • Allerdings entgegnete jemand, „Neues ist instabil und schwer zu lernen“
    Ich denke, Rust ist wegen seiner Speichersicherheit und Ausdrucksstärke die Mühe wert

• Ich frage mich, welche Teile des aktuellen Kernels in Rust geschrieben sind

  • Ein bekanntes Beispiel ist der DRM-Panic-„Screen of Death“, der in Rust geschrieben wurde
    Siehe den Phoronix-Artikel
  • Rust wird vor allem auf der GPU-Treiber-Seite eingesetzt

• Ich frage mich, wie viel unsafe im Rust-Code des Kernels enthalten ist
  Früher gab es viele Beschwerden, dass unsafe zu unbequem sei

  • Der Großteil des unsafe-Codes ist innerhalb der kernel crate verborgen, die mit der C-API interagiert
    Treiberentwickler müssen kaum jemals unsafe verwenden
  • unsafe ist grundsätzlich so entworfen, dass es nur im Randbereichscode (edge) verwendet wird
    Der Großteil des Codes wird in sicherem Rust geschrieben
  • unsafe ist zwar weiterhin schwierig, taucht im eigentlichen Treibercode aber fast nie auf
    Zum Beispiel enthält pwm_th1520.rs
    nur eine einzeilige unsafe-Anweisung zur Unterstützung von Send und Sync
  • Das Prinzip ist, unsafe-Blöcke zu dokumentieren und sie in sichere Interfaces zu kapseln, damit man sie nie wieder direkt sehen muss