© Andrii Zhezhera / 123RF.com

In Dublin trafen die Linux-Entwickler und ihr Chefstratege Linus Torvalds nach längerer Corona-Pause wieder in persona aufeinander. Unter anderem ging es um die Zukunft von Rust und 128-Bit-Systeme. Kurz danach erschien Linux 6.0, das zahlreiche Updates mitbringt.

Dass sich die Nachrichten rund um Linux 6.0 vor allem Mitte September 2022 häuften, ist kein Zufall: Zu diesem Zeitpunkt fand in Dublin nicht nur der Open Source Summit Europe statt, sondern auch die Linux Plumbers Conference [1] und der Linux Kernel Maintainer Summit.

Zwar verschanzten sich die meisten Kernel-Entwickler an einem separaten Konferenzort, doch einige ließen sich auch auf dem Open Source Summit blicken, darunter Linus Torvalds und Dirk Hohndel. Die beiden führten dort ihr übliches Kamingespräch, bei dem Hohndel Fragen stellt und Torvalds antwortet. So richtig zünden wollte der Funke diesmal nicht.

Linus Torvalds erwähnte einmal mehr seinen ARM64-Laptop, ein M2-Macbook mit Asahi Linux, das ihm unter anderem die ARM64-Plattform näherbringen soll. Auch verwies er erneut darauf, dass die Versionsnummer 6.0 für den neuen Kernel keinen Feature-Sprung bedeute: Vielmehr könne er sich die Versionsnummern so leichter merken.

Rust im nächsten Kernel

Spannender wurde es beim Thema Rust. Traditionell dient C als Programmiersprache für den Linux-Kernel und war für viele Kernel-Entwickler daher seit langer Zeit die Sprache der Wahl. Die neue Möglichkeit, Treiber in Rust zu schreiben, mache einige Leute nervös, erklärte Torvalds. Die würden dann anfangen, nach Problemen zu suchen. Er verstehe durchaus, dass nicht alle Entwickler entzückt seien, räumte Torvalds ein. Vielleicht werde man eines Tages auf den Rust-Versuch zurückblicken und feststellen, dass man naiv gewesen sei – er aber finde das Ganze dennoch aufregend.

Jonathan Corbet nannte in seinem Kernel Report weitere Gründe, die für Rust sprechen (Abbildung 1). Der Betreiber von LWN.net und Betreuer der Kernel-Dokumentation argumentierte, dass die Entwickler mit Rust undefiniertem Verhalten von Code weitgehend vorbeugen könnten, also dem Zustand, dass Programme unvorhersehbare Ergebnisse produzieren. Zugleich öffne sich Linux auf diesem Weg einer neuen Generation von Entwicklern, die sich mit der 70er-Jahre-Sprache C nicht mehr wohlfühlen. Am Ende fiel auf dem Gipfeltreffen sogar eine Entscheidung: Rust soll im Linux-Kernel 6.1 landen, sofern keine unvorhersehbaren Hindernisse auftauchen [2].

Abbildung 1: Jonathan Corbet lieferte in seinem Kernel Report eine Bestandsaufnahme zum Linux-Kernel.

Und sonst so?

In seinem ersten Kernel Report nach zwei Jahren erwähnte Corbet noch weitere wichtige Neuerungen, die sich in der Corona-Zeit angesammelt haben. Dazu gehört unter anderem »io_uring«, die API für die asynchrone Ein- und Ausgabe von Daten. Besonders das darin verwendete Konstrukt aus Submission und Completion Queue beschleunigt viele Prozesse im Kernel enorm, da beim Datenaustausch zwischen Kernel- und Userspace Systemaufrufe entfallen. Corbet geht davon aus, dass die meisten Systemaufrufe künftig auch asynchron funktionieren.

Corbet ließ auch die aus seiner Sicht akuten Probleme in der Kernel-Entwicklung nicht aus. So bemängelte er das Fehlen von Diversität im Entwicklerteam und verwies einmal mehr auf das fragile Maintainer-Modell: Die Subsystem-Betreuer seien häufig überlastet und würden bei einem Urlaub oder einer Krankheit schnell zum Single Point of Failure. Sein Vorschlag: Man müsse vom Single-Maintainer-Modell wegkommen und wo immer möglich mehrere Maintainer pro Subsystem einsetzen. Das entlaste die Maintainer und erschüttere bei einem (temporären) Ausfall nicht gleich das komplette Subsystem.

Weiterhin macht ihn der Altersdurchschnitt in der Kernel-Community besorgt. Viele Veteranen seien nicht unbedingt bereit, sich auf Neuerungen einzulassen. Das zeigen zum Beispiel die veralteten Entwicklungswerkzeuge und -prozesse. So findet die Kernel-Entwicklung noch immer in erster Linie über E-Mails statt, eine Technologie, die jüngere Menschen immer seltener nutzen. Er schlug vor, mehr Zeit und Geld in zeitgemäße Tools zu investieren.

Ein plastisches Beispiel für den teils überholten Entwicklungsprozess lieferte Thorsten Leemhuis auf der Plumbers-Konferenz [3]. Er kümmert sich seit einiger Zeit um Regressionen im Kernel, also Code-Commits, die unbeabsichtigt intakte Funktionen des Kernels beschädigen. Beim Auswerten solcher Regressionen auf Bugzilla machte Leemhuis eine Entdeckung: Eine ganze Reihe von Subsystemen reagieren erst spät oder gar nicht auf dort gemeldete Bugs, selbst dann, wenn sich die Bug Reporter die Mühe machen, selbst nach den Ursachen eines Problems zu fahnden.

Was die Bug Reporter oft nicht wissen: In der Regel nehmen die betreffenden Subsysteme Bugs schlicht auf anderen Wegen entgegen, Bugzilla macht dies aber nicht deutlich genug. In Unternehmen angestellten Entwicklern fehlt zudem oft schlicht die Zeit, um sich neben dem Tagesgeschäft noch um die Bugzilla-Pflege zu kümmern. Eine pragmatische Lösung könnte sein, dass die Plattform künftig keine Bug Reports für bestimmte Subsysteme mehr annimmt.

128-Bit-Zukunft

Ansonsten lieferte die Konferenz Gelegenheit, nicht nur aktuelle, sondern auch zukünftige Entwicklungen zu diskutieren. So hielt Matthew Wilcox von Oracle ein Plädoyer dafür, sich allmählich mit 128-Bit-Registerarchitekturen auseinanderzusetzen [4]. Er glaubt, dass solche Architekturen spätestens ab 2035 zum Einsatz kommen, weil auch erste Hardwarehersteller sich damit beschäftigen.

Neu in Kernel 6.0

Freilich gibt es auch Neues vom Kernel 6.0 zu berichten. Da wäre etwa das lange erwartete Update auf Version 2 für das Send-Protokoll von Btrfs. Es erlaubt unter anderem den Einsatz neuer Kommandos für das Dateisystem, ohne die Rückwärtskompatibilität zu brechen. Zum vollendeten Glück fehlen jedoch noch einige Befehle [5].

Die Updates am Dateisystem XFS betreffen unter anderem das XFS-Log, das nach dem Entfernen von Spinlocks und globalen Synchronisierungspunkten besser skaliert. Zudem ermöglicht XFS neuerdings schnelle und nicht blockierende Abfragen des Puffer-Caches [6].

Neue Systemaufrufe ermöglichen es Ext4-Entwicklern, die Dateisystem-UUID im Superblock zu setzen und zu lesen. Zugleich erlaubt Ext4 seit Kernel 6.0, die Größe des Dateisystems im laufenden Betrieb schneller zu verändern, wenn es Bigalloc verwendet [7]. Letzteres erlaubt den Einsatz von Ext4 mit geclusterten Block-Allokationen.

Beim Daemon für das Network File System (NFS) geht die Arbeit am “höflichen” Server weiter. Die erlaubte Menge an NFSv4-Clients lässt sich nun flexibler einstellen. Das Limit richtet sich dabei nach der vorhandenen Menge an Speicher auf dem Server. Zugleich skaliert der NFSD-Filecache besser.

Interna

Um Linux auf sicherheitskritischen Systemen zu betreiben, benötigt der Kernel eine Laufzeit-Verifizierung (Runtime Verification). Laut Steven Rostedt ist diese ab Kernel 6.0 im Tracing-Bereich verfügbar. Sie erlaubt es, deterministische Automatenmodelle in den Kernel einzufügen, die sich an Tracepoints heften und die Zustände verfolgen. Passt ein State nicht zum Modell, triggert das bestimmte Reaktionen, von einem simplen Protokolleintrag bis hin zur Kernel Panic.

Von »io_uring« war bereits die Rede. Neu ist hier die Option, beim Senden großer Datenmengen Zero-Copy zu verwenden, um den Arbeitsspeicher und die CPU in hoch-frequentierten Netzen zu entlasten [8]. Das funktioniert für IPv4, IPv6, TCP und UDP. Auch Zero-Copy Receive ist bereits in Arbeit. Zudem unterstützt »io_uring« neuerdings gepufferte Schreibvorgänge für das Dateisystem XFS, mit Btrfs als Ziel für das nächste Release [9]. Obendrein haben Jens Axboe und seine Entwickler den Code von »io_uring« neu strukturiert, um ihn für die verschiedenen Sub- und Dateisysteme leichter nutzbar zu machen.

Das Clock Framework »clk« hat anders als der Name vermuten lässt nicht viel mit Zeitmanagement zu tun. Vielmehr verwalten SoCs damit Signale für das Power Management. Es erhält im aktuellen Kernel ein neues Set an APIs. Sie erlauben es den Treibern, Clocks nicht nur anzufordern, sondern auch vorzubereiten und zu aktivieren. Laut Stephen Boyd ist das ein lange gefordertes Feature, über dessen Implementierung jedoch bisher Uneinigkeit bestand. Nun werde man sehen, wie Interessierte es in der Praxis aufnehmen, um daraus weitere Schritte abzuleiten.

Plattform

Für die ARM64-Plattform haben die Entwickler nicht nur den Code für die Kernel Page Table Isolation (KPTI) überarbeitet, sondern auch die Frühphase im Boot-Code vereinfacht. Sie wollen so den Aufwand für die Daten-Cache-Pflege reduzieren, den die Kernel Address Space Layout Randomization (KASLR) häufig nach sich zieht. Bei den ARM-SoC-Treibern gibt es mittlerweile besseren Support für das Power Management im Raspberry Pi 4 (BCM2711), was den Einsatz der V3D-GPU erlaubt.

Maintainer Hans de Goede lieferte Änderungen für die x86-Plattform, die unter anderem den Schutzdeckel für das Microsoft Surface Pro 8 betreffen. Neuerdings steuert das Surface System Aggregator Module (SSAM) diesen Deckel. Da die Nutzer ihn auch abnehmen dürfen, muss der HID-Code dieses Entfernen und Anbringen unterstützen. Zudem funktioniert nun der Wechsel in den Tablet-Modus für das Pro 8 und das Surface Laptop Studio.

Grafik

Nicht zuletzt warten spannende Neuerungen im Grafikbereich auf Linux-Anwender. Die Arbeit an DG2 geht unter dem Codenamen Intel Arc Alchemist weiter, Code-Änderungen landen bereits im Treiber »i915«.

Bei Intels Arc Alchemist handelt sich um Desktop-GPUs, die erstmals mit den Grafikkarten der Platzhirsche AMD und Nvidia mithalten sollen. Das ist ein Novum, waren Intels Grafikprozessoren doch bislang für Gamer eher uninteressant. Laut Phoronix spielen die neuen GPUs etwa in der Liga der GeForce RTX 3060 [10] und sind zugleich komplett quelloffen. Das ist auch deshalb eine gute Nachricht, weil Linux dank des Valve-Supports und des Steam Decks damit zunehmend für Spieler interessant wird, die sich nicht nur für Retro-Games interessieren. Die entsprechenden Grafikkarten A750 und A770 sind noch für diesen Herbst angekündigt. Für den »i915«-Treiber gibt es außerdem ersten Support für “Meteor Lake”, Intels 14. CPU-Generation.

Ansonsten erlaubt der »fbcon«-Treiber für die Framebuffer-Konsole nun ein besseres Scrollen. Über das EDID-Format (Extended Display Identification Data) weisen Monitore nach einem standardisierten Verfahren ihre Fähigkeiten aus. Der überarbeitete EDID-Parser akzeptiert jetzt neue Erweiterungen.

Ein- und Ausblicke

Sämtliche Videos von der Konferenz warten auf Youtube auf Schaulustige [11]. Wer den Kernel 6.0 testen möchte, findet ihn auf Kernel.org [12]. Für die meisten Anwender ist es aber sinnvoller zu warten, bis die jeweilige Distribution der Wahl die neue Version unterstützt. Zugleich hat Linus Torvalds das Merge Window geöffnet und für Kernel 6.1 bereits größere Änderungen angekündigt [13]. (uba/jlu)