Linux 6.11: Mehr Rust, Torvalds ergänzt "Runtime Constants"

Inhaltsverzeichnis

In der Nacht von Sonntag auf Montag erblickte die neueste Inkarnation des Linux-Kernels das Licht der digitalen Welt. War für Linux 6.11 mit Spannung der "extensible Scheduler" erwartet worden, bleibt der neue Scheduler erst mal außen vor. Dafür bringt der Linux-Vater Torvalds selbst einen Mechanismus für "Runtime Constants" ein. Zudem geht der Rust-Ausbau voran.

Kein extensible Scheduler

Entgegen den Plänen von Linus Torvalds, den extensible Scheduler (sched_ext) in Linux 6.11 aufzunehmen, ist dieser nun nicht Bestandteil des neuen Kernels. Torvalds wollte den flexiblen, auf eBPF setzenden Scheduler eigentlich nicht länger auf die lange Bank schieben. Etwaige auftretende Probleme sollten die Entwickler künftig mit vereinten Kräften im Mainline-Kernel klären. Torvalds machte einmal mehr klar, dass er kein Freund von außerhalb des Kernels (out of tree) entwickelter, neuer Features ist. Bislang ist dies dem extensible Scheduler der Fall.

Seit Torvalds' Ankündigung, den eBPF-basierten Scheduler aufzunehmen, ergaben sich einige Probleme mit dessen Code. Er "vertrug" sich nicht mehr so glatt mit dem Rest der Kernels. Die für Linux 6.11 per Pull-Request von Tejun Heo eingereichten zusätzlichen mehr als 14.000 Zeilen Code rund um den Scheduler berücksichtigte Torvalds nicht. Sein Ablehnen kommentierte Torvalds nicht.

Ein Kommentar von Qais Yousef spricht jedoch die vermutlich fürs Ablehnen verantwortlichen Gründe an. Das Verhalten des Schedulings und des Kernels würde sich voraussichtlich stark verändern, wenn der sched_ext geladen würde. Wie könne man Bug-Reports und Regressionsberichten noch vertrauen, wenn das Verhalten des Kernels massiv verändert würde, argumentiert Yousef. Die Aufnahme sei überstürzt und ginge in die falsche Richtung. Damit bleibt sched_ext erst einmal außen vor. Wann und in welchem Linux-Release der neue zusätzliche Scheduler in den Mainline-Kernel einzieht, ist aktuell unbekannt.

Block-Devices in Rust

Der neue Kernel unterstützt erstmals das Programmieren von Treibern für blockorientierte Geräte (Block-Devices) in Rust. Damit lassen sich grundsätzlich Treiber beispielsweise für Festplatten oder DVD-Laufwerke schreiben. Zwar nutzt das bislang lediglich der Null-Block-Treiber, aber das Entwickeln von Block-Device-Treibern im Mainline-Kernel in Rust soll damit erleichtert werden.

Der Null-Block-Treiber emuliert blockorientierte Geräte und stellt diese als /dev/nullb0, /dev/nullb1 et cetera zur Verfügung. Er kommt bei Benchmarks für Block-Layer-Implementierungen zum Einsatz und ist damit nicht für produktive Systeme vorgesehen, sondern dient der Entwicklung und Tests. Zudem ist er ein sehr einfacher Treiber mit überschaubarem C-Quellcode.

Diese Eigenschaften machten ihn zum idealen Kandidaten, um gefahrlos die ersten Gehversuche mit Blockgeräten in Rust zu wagen. Der Rust-Treiber rnull steht in der Kernel-Konfiguration (make menuconfig) in den Block-Devices als BLK_DEV_RUST_NULL zur Auswahl. Einmal ausgewählt, fungiert er als experimenteller Ersatz für das "normale" Null-Block-Gerät. Er ist allerdings bislang nur eine "Sparversion" des ursprünglichen Treibers.

Firmware per Rust

Zudem steht nun eine Abstraktionsschicht für die Firmware-API von Linux zur Verfügung. Das ist ein erster Schritt zum Laden von Firmware aus Rust-Code heraus. Die API erlaubt das Laden von Firmware-Updates aus dem Userspace heraus. Auf diesem Weg lassen sich etwa Fehler im Mikrocode der Prozessoren beseitigen oder auch Firmware für Mikrocontroller auf Geräten wie Datenträgern, Erweiterungskarten und Controller aktualisieren.

Diese Abstraktionsschicht ist notwendig, um zukünftig "echte" Treiber für Geräte in Rust programmieren zu können. Schließlich werden praxistaugliche Rust-Treiber auch die Firmware der zugehörigen Geräte anpassen können. Ein weiteres Puzzleteil für das Gesamtbild "Gerätetreiber in Rust" ist damit gelegt. Allerdings fehlen noch einige weitere Teile, bis sich beliebige Treiber in Rust genauso wie in C programmieren lassen. Die Lücken im Bild schrumpfen langsam, aber sicher.