Linux 5.2 freigegeben: Änderungsrekord und Geschwindigkeitsverbesserungen

Das Ext4-Dateisystem kann jetzt Groß- und Kleinschreibung ignorieren. Die Storage-Performance legt in gewissen Konstellationen deutlich zu. ISDN4Linux fliegt bald raus. Außerdem ist es jetzt ganz leicht, Schutztechniken auszuschalten, die viel Leistung kosten.

In Pocket speichern vorlesen Druckansicht 1036 Kommentare lesen
Linux Kernel 5.2
Lesezeit: 46 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Linus Torvalds hat Sonntagnacht die Linux-Version 5.2 freigegeben. Wie jede neue Version der Hauptentwicklungslinie bringt auch der neueste Kernel weit über zehntausend Änderungen. Einige rüsten neue Features nach, andere verbessern existierende. Die wichtigsten Verbesserungen im Kurzüberblick:

  • Das populäre Ext4-Dateisystem kann jetzt die Groß- und Kleinschreibung ignorieren, wie es XFS ähnlich schon länger kann; diese unter anderem für Android gedachte "Case Insensitivity" muss man aber explizit mit neuer Software aktivieren.
  • Bei Linux 5.2 lässt sich leicht etwas Performance locker machen, wenn man nur vertrauenswürdigen Code auf seinen Systemen ausführt.
  • Die früher viel genutzten, mittlerweile aber exotischen IDE-Treiber stehen jetzt auf der Abschussliste. Auch ISDN4Linux soll bald rausfliegen.
  • Die Kernel-Entwickler haben die Performance einer Technik verbessert, die beim Datenträgerzugriff die Operationen umsortieren kann, um Vordergrundprogramme zu bevorzugen.
  • Linux 5.2 kann die Dateien via Procfs bereitstellen, die man zum Bau von Kernel-Modulen braucht.
  • Durch neue und verbesserter Grafiktreiber unterstützt der Kernel jetzt die Grafikkerne, die Intel in drei neuen Prozessorgenerationen einsetzt.
  • Linux bringt endlich Treiber für die 3D-Grafikeinheit mit, die in vielen Einplatinencomputern mit ARM-SoC (System-on-a-Chip) steckt.
  • Überwachungsprogramme können jetzt die Auslastung besser im Blick behalten, um gegebenenfalls ohne viel Overhead und zeitnah Gegenmaßnahmen ergreifen zu können. Android soll das nutzen.
  • Die Entwickler haben Lizenzauszeichnungen eingeführt, durch die diesmal über zweieinhalb mal so viele Dateien verändert wurden wie sonst für eine neue Version.
  • Der Kernel bringt jetzt Treiber für einige Audio-Chips mit, die eine Open-Source-Firmware verwenden, die Intel und Google vorantreiben.
  • Zum Lieferumfang gehören jetzt zwei weitere WLAN-Treiber für Chips von Realtek und Mediatek.
Mehr Infos

Dies war ein schrittweise aktualisierter Artikel

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen in Linux 5.2 zu beschreiben. Zur jüngst erfolgten Freigabe dieser Kernel-Version haben wir die Abschnitte umsortiert und Abschnitte zu wichtigeren Neuerungen an den Anfang gestellt. Von nun an behält der Text seine jetzige Form. Details zur Versionshistorie des Artikels finden Sie am Artikelende.

  • Wichtige Daten für die Performance-Analysen oder die Ablaufverfolgung lassen sich jetzt deutlich effizienter beim Kernel hinterlegen.
  • In der BPF Virtual Machine im Kernel ausgeführte Programme können nun deutlich komplexer sein.
  • Über eine neue Intel-Technik lassen sich jetzt Funktionen von Hardware kleinteiliger an virtuelle Maschinen oder Container überstellen, ohne den Host zu gefährden.
  • Die Entwickler haben den Support für virtuelle Maschinen und erweiterte Farbräume optimiert.
  • Unterstützung für AMDs neue Grafikprozessorgeneration steht für Linux 5.3 auf der Agenda.

Die folgenden Seiten liefern zahlreiche wichtige Details zu diesen Neuerungen von Linux 5.2 und erläutern darüber hinaus zahlreiche weitere Änderungen.

Ein ganzer Schwung von Änderung verspricht die Performance von Budget Fair Queueing (BFQ) zu verbessern – dem von manchen Distributionen standardmäßig eingesetzten Storage-I/O Scheduler, der bei Datenträgerzugriffen die gerade anstehenden Lese- und Schreiboperationen umsortieren kann, um die Performance zu verbessern.

Eine der Anpassungen an BFQ hat bei einem Test der Entwickler größere Auswirkungen gezeigt: Der Test Dbench legte bei sechs Clients bei einem System mit Plextor-SSD von 80 MByte/s auf 100 zu. Bei einer weiteren Änderung am Nachfolger des früher verbreiteten I/O-Scheduler CFQ (Completely Fair Queuing) ist von einem Zugewinn von 100 auf 150 MByte/s die Rede – anscheinend geht es hier um dasselbe Testsystem. Damit nicht genug: Durch einen dritten Patch stieg das Testergebnis von 150 auf 200 MByte/s. Wie bei solchen Messungen üblich, hängt stark von Umgebungsbedingungen, Benchmark und Testparametern ab, ob es in anderen Situationen überhaupt einen Performance-Gewinn gibt und wie groß dieser ausfällt.

Der BFQ-Entwickler hat viele Messwerte mit der modernen BFQ-Ausführung veröffentlicht.

(Bild: algo.ing.unimo.it/people/paolo/ )

Durch andere Änderungen an BFQ sollen Programme um einiges schneller starten, wenn parallel viele Schreiboperationen anliegen. Einige weitere Verbesserungen versprechen die CPU-Belastung zu reduzieren. Details zum Ganzen liefert der LWN.net-Artikel "Improving the performance of the BFQ I/O scheduler", der noch andere Testergebnisse enthält; weitere hat der Hauptentwickler von BFQ auf seiner Homepage veröffentlicht.

Was in der Windows-Welt ganz normal ist, kann Ext4 jetzt auch: Die Groß- und Kleinschreibung von Datei- und Verzeichnisnamen ignorieren. Durch diese "Case Insensitivity" wechselt etwa das Bash-Kommando cd Test in ein Verzeichnis, egal, ob es jetzt TEST, test oder tatsächlich Test heißt.

Dieses Verhalten ist standardmäßig inaktiv. Wer es nutzen will, muss es zuerst beim jeweiligen Dateisystem im Superblock freischalten, indem man das Feature-Flag casefold gleich beim Formatieren oder nachträglich mit tune2fs setzt; dazu braucht man aktuelle Fassungen der Ext-Dateisystemwerkzeuge e2fsprogs. Ältere Kernel oder Image-Werkzeuge, die mit dem Flag nichts anzufangen wissen, sollten so ein Dateisystem dann nicht mehr anfassen und somit auch nicht mounten. Ungewiss ist, ob Debian, Fedora, Ubuntu & Co. die Kennzeichnung in Zukunft automatisch setzen.

Das Verhalten muss man ferner beim Hauptverzeichnis oder einem Unterverzeichnis aktivieren, indem man dort mit aktuellen Versionen von chattr das Flag F setzt. Das Verzeichnis muss dazu noch leer sein, damit das Dateisystem dort fortan das Anlegen mehrdeutiger Dateisystemeinträge wie TEST und test unterbinden kann. Die Einstellung vererbt sich, sodass Unterverzeichnisse das Verhalten übernehmen.

Entwickler haben dieses "Casefold Feature"-Feature entwickelt, um es bei Android einzusetzen – bislang nutzt das Mobilbetriebssystem einen eher uneleganten Hack in Form einer "Wrapfs" genannten Zwischenschicht, um Case Insensitivity mit Ext4 zu erzielen. Das neue Ext4-Feature ist aber auch bei den Entwicklern von Wine auf Anklang gestoßen – kein Wunder, schließlich kann das eine Reihe von Windows-Programmen unter Linux ausführen, die eben Case Insensitivity erwarten. Die Wine-Macher haben daher in den Test-Entwicklungszweig Wine Staging bei Version 4.10 eine neue Funktion eingebaut, um mit dem Casefold Feature einige Tücken rund um die Groß- und Kleinschreibung von Verzeichnis- und Dateinamen zu vermeiden.

Case Insensitivity ist in der Linux-Welt übrigens nichts Neues: Auch beim angesehenen und unter anderem von Red Hat (Root- und Datenpartitionen) und Suse (bei Datenpartitionen) verwendete Dateisystem XFS lässt sich Case Insensitivity seit vielen Jahren beim Formatieren mit dem Parameter -l version=ci aktivieren. XFS ignoriert Groß- und Kleinschreibung aber nur im Bereich der ASCII-Zeichenkodierung – letztlich also nur von A bis Z, was recht simpel und nebenwirkungsfrei zu implementieren ist.

Das Casefold Feature von Ext4 greift hingegen für Normalisierung und Casefolding auf eine UTF-8-Zeichentabelle der Unicode Version 12.1.0 zurück. Sie wurde eigens für die neue Dateisystemfunktion in Linux integriert und ist über 1 MByte schwer (u. a. 1, 2, 3).

Linus Torvalds hatte sich anfangs deutlich gegen Case-Insensitivity bei Ext4 ausgesprochen.

(Bild: lore.kernel.org )

Weitere Details zum neuen Feature und der Verwendung von Unicode-Tabellen im Kernel liefert ein Commit-Kommentar, die Dokumentation sowie die LWN.net-Artikel "Filesystems and case-insensitivity" und "Case-insensitive ext4". Letzterer zeigt auch, dass die Entwickler über die Funktion anfangs gezankt haben. Selbst Linus Torvalds hatte sich zuerst dagegen ausgesprochen und den ganzen Ansatz zuerst mit deutlichen Worten in Frage gestellt: "Himmel! Warum wollen Leute das machen? Wir wissen doch, dass es eine verrückte und beknackte Sache ist. […] Sowas löst echte und subtile Sicherheitslücken aus". Letztlich hat er die Änderung aber ohne Widerworte für 5.2 integriert (1, 2).

Die Linux-Entwickler haben für Linux 5.2 nicht wie sonst elf- bis dreizehntausend Dateien verändert, sondern über dreißigtausend. Für diesen Rekord sind Thomas Gleixner und einige Mitstreiter verantwortlich, die tausende Lizenzhinweise in Quelltextdateien durch einzeilige Lizenzauszeichner ersetzt haben, die der Spezifikation des SPDX (Software Package Data Exchange) entsprechen. Diese am Dateianfang stehenden "SPDX License Identifier" lauten etwa "GPL-2.0-or-later" oder "GPL-2.0-only". Compliance-Werkzeuge können diese leicht und unmissverständlich abfragen. Vor allem Unternehmen setzen solche Werkzeuge ein, um sich einen Überblick über die in Produkten verwendeten Software-Lizenzen zu verschaffen, damit sie besser sicherstellen können, die Lizenzen auch einzuhalten.

Die Bestrebungen zur SPDX-Auszeichnung der Quelldateien von Linux begannen bei Linux 4.14 und bekamen bei Linux 4.16 einen ersten Schub. Die jetzt vorgenommenen Änderungen (u. a. 1, 2, 3, 4, 5, 6) sind ein enormer Schritt vorwärts, durch den jetzt statt zirka 25 rund 70 Prozent der Dateien einen SPDX License Identifier tragen.Die Änderungen nahmen die Entwickler im Wesentlichen mit Skripten vor. Bei den verbliebenen Dateien ist mehr Handarbeit nötig, weil die Skripte die Lizenzen dort nicht zweifelsfrei erkennen können.

Mehr als siebzig Prozent der Quellcode-Dateien tragen jetzt eine unmissverständliche Lizenz-Kennzeichnung.

Linux kann über die Datei /proc/kheaders.tar.xz jetzt eine Reihe von Entwicklerdateien bereitstellen, die man für Kernel-nahe Tätigkeiten gelegentlich braucht – etwa zur Ablaufverfolgung (Tracing) oder zum nachträglichen Kompilieren von Kernel-Modulen. Die Datei mit Header- und Devel-Dateien wird dabei von einem vergleichsweise großen Modul bereitgestellt, das sich bei Bedarf aber laden und später wieder entladen lässt.

Laut dem zuständigen Entwickler ist dieser Ansatz für Android und andere Embedded Systems gedacht: Dort ist es unüblich, diese Entwicklerdateien mit dem Root-Dateisystem auszuliefern, wie es Linux-Distributionen für PCs typischerweise machen. Abzuwarten bleibt, ob Distributoren das neue Feature in ihren Kernel-Images aktivieren werden.

Mithilfe des von Google-Mitarbeitern eingebrachten PSI Monitors (u. a. 1, 2) können Überwachungsprogramme jetzt innerhalb von Millisekunden und ohne viel Overhead von drohender oder akuter Überlastung erfahren. Solche Tools können früher Maßnahmen ergreifen und notfalls Programme beenden – etwa wenn ein Hintergrundprozess den Arbeitsspeicher übermäßig belastet und so die Desktop-Oberfläche oder ein Vordergrundprogramm spürbar verlangsamt.

Google will das Feature bei Android nutzen. Einige Hintergründe zum Ansatz erläutert der LWN.net-Artikel "Pressure stall monitors". Die neue Technik erweitert das bei Linux 4.20 integrierten PSI (Pressure-Stall Information), mit dem Administratoren deutlich leichter als bei /proc/loadavgerkennen können, wie stark und wodurch ein System ausgelastet is.

Der Kernel-Grafiktreiber i915 unterstützt jetzt die GPU von Intel-Prozessoren mit dem Codenamen "Ice Lake". Zu ihr gehören etwa die ersten Core-i-CPUs der zehnten Generation, die Intel kürzlich vorgestellt hat und die für flache Notebooks ausgelegt sind. Diese 10-nm-Prozessoren sind die ersten, in denen Intels Grafikprozessor der elften Generation sitzt. Support für solche Gen11-GPUs steckt auch schon in den Vorgängern von Linux 5.2 – er gilt dort aber als unvollständig, daher muss man ihn über den Kernel-Startparameter i915.alpha_support=1 explizit aktivieren. OpenGL- und Vulkan-Treiber für diese Chips bringt das im Juni erwartete Mesa 19.1.

Linux 5.2 unterstützt die GPUs einiger kürzlich eingeführter oder bald erwarteter Intel-Prozessoren.

(Bild: c't-Online-Artikel "Prozessorfahrpläne von AMD und Intel" )

Der neue Kernel unterstützt auch schon die GPUs der noch nicht erhältlichen Intel-Platform "Elkhart Lake (EHL)", die wie Ice Lake eine Gen11-GPU enthält, aber auf Embedded-Prozessoren (Atom) und Billig-CPUs (Atom-Celerons) zielt. Ferner weiß der Kernel jetzt auch den Grafikprozessor von CPUs der "Comet Lake"-Generation inklusive ihres Platform Controller Hubs (PCH) anzusprechen. Auch sie sind noch nicht erhältlich und für Desktop-PCs und leistungsstärkste Notebooks gedacht. Weitere Details zu den Einsatzgebieten von diesen und weiteren jüngst eingeführten oder bald erwarteten Prozessoren liefert der kürzlich auf c't online veröffentlichte Text "Prozessorfahrpläne von AMD und Intel".

Für die verbreiteten ARM-GPUs der Mali-Reihe bringt der Direct Rendering Manager (DRM) des Kernels jetzt die Grafiktreiber Lima und Panfrost mit. Auf ihnen bauen gleichnamige OpenGL-Treiber zur 3D-Beschleunigung auf, die zu den wichtigsten Neuerungen des kürzlich veröffentlichten Mesa 19.1 gehören. Über diese Treiber lässt sich die 3D-Beschleunigung der meisten von ARM entwickelten Mali-GPUs nutzen, die diverse Hersteller in System-on-a-Chip-Bausteinen (SOCs) in Android-Geräten, Chromebooks, Embedded Systems oder Einplatinensystemen (Single Board Computer/SBCs) einsetzen.

Das Duo aus Lima-DRM-Treiber und Lima-OpenGL-Treiber unterstützt dabei "Utgard"-GPUs der Mali-400er-Serie. Das Panfrost-Duo hingegen spricht die neueren Mali-Generationen "Midgard" und "Bifrost" an, die unter den Mali-Modellbezeichnungen T6xx, T7xx, T8xx respektive G3x, G5x, G7x segeln.

Mehr Infos

Viele Treiber für einen Chip

Die in Linux 5.2 enthaltenen Kernel-Treiber Lima und Panfrost stellen DRM Render Nodes bereit, mit denen die gleichnamigen OpenGL-Treiber von Mesa 19.1 die 3D-Beschleunigung vieler Mali-Kerne nutzen können. Mit der Monitoransteuerung haben Lima und Panfrost allerdings nichts zu tun: Anders als bei x86-PCs sind Display Engine, 3D-Einheiten und Video-Beschleuniger bei SoCs nicht Teil eines mächtigen Grafikchipdesigns; vielmehr kümmern sich separate Komponenten um diese drei Funktionen, die SoC-Hersteller als IP-Cores von einem oder unterschiedlichen Unternehmen zukaufen und kombinieren.

Neben Lima oder Panfrost ist daher ein weiterer Kernel-Treiber für die Display Engine nötig, die den Bildschirm ansteuert (und sich oft abermals aus verschiedenen IP-Cores zusammensetzt). Solche zumeist Kernel-based Mode-setting (KMS) bietenden Treiber gibt es aber für die meisten SoCs mit Mali-GPUs; typischerweise sind sie auch Open-Source-Software und bereits in Linux enthalten. Für Video-Beschleuniger bedarf es ähnlich wie bei 3D eigener Treiber sowohl im Kernel als auch im Userspace.

An der Entwicklung von Lima und Panfrost hat sich ARM nicht beteiligt, obwohl die Firma in nahezu allen anderen Bereichen eigenhändig für ordentliche Linux-Unterstützung ihrer Hardware-Designs sorgt. Die zwei neuen Treiber-Duos entstanden daher weitgehend mithilfe von Reverse Engineering, indem unabhängige Entwickler das Verhalten von Hardware mit anderen, teilweise proprietären Treibern analysiert haben. So konnten sie alle zur Treiberprogrammierung benötigten Informationen zusammenkratzen, denn ARM stellt diese nicht bereit. Durch diesen Entwicklungsansatz beherrschen die beiden Treiber-Duos allerdings nur einen Teil der Funktionen, die die Hardware bietet. Außerdem unterstützen die Treiber längst nicht alle Grafikkerne der erwähnten Serien; Panfrost wurde beispielsweise nur auf den Midgard-GPUs T760 und T860 getestet.

Vermutlich stehen deshalb noch etliche Probleme und Stolpersteine mit den DRM- und OpenGL-Treibern an. Die Aufnahme der Treiber in Linux und Mesa hat erfahrungsgemäß aber starke Signalwirkungen, durch die sich mehr Tester und Entwickler auf die Treiber stürzen – das dürfte der Treiberqualität und dem Umfang der Hardware-Unterstützung einen ordentlichen Schub gehen.

ARM beobachtet die Entwicklung genau und erwägt offenbar, sich zumindest bei den Kernel-Treibern einzubringen. Offenbar gibt es zudem ARM-Entwickler, die das Unternehmen intern drängen, sich stärker zu engagieren. Das zeigt sich etwa im Zeitabschnitt 23:23 bis 28:44 eines Videos einer jüngst abgehaltenen Linaro-Konferenz, wo der angesehene und neuerdings bei ARM arbeitenden Linux-Entwickler Grant Likely einige diesbezügliche Andeutungen macht.

Sie wollen auf ihrem PC das Maximum an Geschwindigkeit herauskitzeln und fürchten sich nicht vor den ganzen Sicherheitslücken moderner Hauptprozessoren, die seit Anfang 2018 publik wurden? Dann starten Sie den Kernel fortan mit dem neuen Parameter mitigations=off, denn der deaktiviert die vielen Schutztechniken, die der Kernel für diese Lücken erhalten hat und standardmäßig nutzt. Wie stark das die Performance steigert, hängt von Prozessor und der eingesetzten Software ab: Die Gegenmaßnahmen machen manche Workloads deutlich langsamer, andere nur minimal.

Über den neuen Kernel-Parameter "mitigations=" kann man Maßnahmen für Prozessorlücken lahmlegen und so die Performance steigern.

(Bild: Screenshot der Kernel-Dokumentation)

Unterstützung für diesen Parameter wurde in den Hauptentwicklerzweig integriert, als dort im "Merge Window" gerade das Gros der Änderungen für Linux 5.2 zusammengetragen wurde (u. a. 1, 2, 3). Ein paar Tage später flossen dort auch die Gegenmaßnahmen ein, die vor "ZombieLoad" und anderen als MDS (Microarchitectural Data Sampling) klassifizierten Lücken schützen, die im Mai publik wurden.

Diese Schutztechniken und Support für den Mitigations-Parameter wurden aber am selben Abend in die Linux-Versionen 5.1.2, 5.0.16, 4.19.43, 4.9.176 und 4.14.119 zurückportiert. Auch mit vielen Kerneln von Linux-Distributionen funktioniert der Parameter mittlerweile. Er legt neben dem MDS-Schutz unter anderem auch PTI oder Retpoline lahm, die vor Meltdown und Spectre v2 schützen. Bislang musste man jede dieser Gegenmaßnahmen mit einem eigenen Parameter individuell ausschalten. Man sollte diese Möglichkeit aber nur in Umgebungen nutzen, wo keine Gefahr droht oder diese vernachlässigbar klein ist – beispielsweise in einem Hochgeschwindigkeits-Rechenverbund (HPC-Cluster), in dem man nur hausintern erzeugte und vertrauenswürdige Programme ausführt.

Mit dem neuen Parameter kann man die Sicherheit indes auch verbessern: Durch ein mitigations=auto,nosmt deaktiviert Linux falls nötig auch Hyper-Threading, denn das birgt bei einigen Prozessoren und Lücken zuständliches Gefahrenpotenzial. Ein solcher Schritt drückt die Performance aber noch stärker, als es die Gegenmaßnahmen ohnehin schon tun. Nach derzeit gängiger Auffassung ist das für Desktop-Systeme zu viel des Guten. Für Cloud-Provider und einige andere Einsatzgebiete kann das Deaktivieren von Hyper-Threading aber angebracht sein.

Beim XFS-Dateisystem gab es einen größeren Batzen von Neuerungen, die ein Commit-Kommentar nennt. Darunter etwa eine Schnittstelle, über die das Dateisystem jetzt Informationen zum Gesundheitszustand des Dateisystems abliefern kann. Der Code zum Prüfen der Metadaten im Betrieb bleibt experimentell, bietet nach einer Erweiterung aber jetzt alle wesentlichen Funktionen, auf die Oracle-Entwickler Darrick Wong seit einiger Zeit im Rahmen eines größeren Umbaus hinarbeitet.

Auch beim Device Mapper (DM), auf den unter anderem der Logical Volume Manager oder die Datenträgerverschlüsselung mit Cryptsetup/LUKS zurückgreifen, gab es allerlei Änderungen. Eine davon ist ein Bitmap-Mode für Dm-Integrity (1, Dokumentation); diese Device-Mapper-Funktion zur Sicherstellung von Datei-Integrität soll damit eine bessere Performance erzielen als mit dem älteren Ansatz, der ein Journal verwendet. Neu ist das DM-Dust-Target, mit dem man zu Testzwecken das Verhalten eines gealterten Datenträgers simulieren kann, der defekte Sektoren aufweist.

Das beim Zugriff auf SMB-Freigaben von Samba- oder Windows-Servern verwendete CIFS beherrscht jetzt die lseek()-Flags SEEK_DATA und SEEK_HOLE. Auch das Overlay-Dateisystem (OVL) unterstützt sie jetzt. Diese Funktionen sind unter anderem zur effizienteren Handhabung von Images virtueller Maschinen interessant, denn Anwendungen können darüber Speicherbereiche in Dateien effizienter handhaben, die lediglich Nullen enthalten.

Unter den Änderungen an CEPH ist Unterstützung für den bei Linux 4.11 eingeführten Systemfunktionsaufruf statx(), der eine umfassendere und effizientere Abfrage von Datei- oder Verzeichniseigenschaften ermöglicht. Außerdem kann es jetzt NFS-Snapshots re-exportieren.

Beim ursprünglich für simple Flash-Datenträger gedachten F2FS-Dateisystem haben die Entwickler unter anderem den Support für Festplatten verbessert, die mit Shingled Magnetic Recording (SMR) arbeiten; bei solchen gibt es größere, Zonen genannte Bereiche, die immer sequenziell gefüllt werden müssen.

Das bei Linux 5.1 eingeführte, dort aber allenfalls intern verwendete Programmier-Interface zum Einhängen von Dateisystemen lässt sich bei 5.2 jetzt auch von Userspace-Programmen verwenden (u. a. 1, 2, 3, 4, 5). Der zuständige Entwickler will mit diesen neuen Mount-APIs eine Reihe von Problemen der bisherigen Schnittstelle aus der Welt schaffen.

Weitere Neuerungen nennen die wichtigsten Git-Commits der Bereiche AFS, Btrfs, Block-Layer (1, 2), CIFS (1, 2), Fuse, GFS, IO-Uring, MTD, NFS, NFSd, Orangefs, SCSI und Ubifs.

Eigentlich nur für Nostalgiker interessant ist eine Detailänderung, die im Internet aber viel Aufsehen erregte: Zwei Linux-Entwickler haben angekündigt, 2021 die Infrastruktur und die Treiber entfernen zu wollen, die via Parallel-ATA (auch PATA beziehungsweise IDE/Integrated Drive Electronics genannt) angesprochene Datenträger über Gerätenamen wie /dev/hda oder /dev/hdc bereitstellen.

PATA-Datenträger über diesen Code und solche Gerätenamen anzusprechen war in der Anfangszeit von Linux Usus. Mit dem Aufkommen von Serial ATA erhielt der Kernel aber eine modernere Infrastruktur samt neuer Treiber zum Austausch mit ATA-Datenträgern, die Linux dann unter Block-Devices wie /dev/sda, /dev/sdb, usw. bereitstellt. Dieses Libata genannte Subsystem erhielt wenig später auch alles Nötige, um gängige PATA-Chips anzusprechen. Damit hat Libata die ältere, oft schlicht "IDE-Treiber" genannte Infrastruktur schnell zurückgedrängt, sodass moderne Systeme auch PATA-Datenträger über /dev/sd? ansprechen.

Die Entwickler vermuten daher, dass kaum noch jemand die ältere Infrastruktur bei aktuellen Kernel-Versionen nutzt. Sofern niemand Einspruch erhebt, wollen sie den zuständigen Code entfernen, um die Wartung zu vereinfachen. Da die Parallel-ATA-Treiber auf Libata-Basis im Kernel bleiben, hat dieser Schritt für die meisten Anwender keinerlei Bedeutung.

Bei Linux kann man jetzt IPv6-Gateways in IPv4-Routen definieren; damit kann man jetzt einen Weg zu einem IPv4-Netz festlegen, das über ein IPv6-System erreichbar ist.

Einen Performance-Zuwachs auf Systemen mit vielen CPU-Kernen versprechen einige Locking-Optimierungen am Cache für empfangene und versendete Pakete; ein Benchmark mit Remote Procedure Calls (RPCs) legte dadurch laut Entwickler um zehn Prozent zu.

Der neue Kernel verspricht kleinere Performance-Verbesserungen bei der Steuerung des Netzwerkverkehrs via tc (Traffic Control), denn die Entwickler haben auch die Locking-Mechanismen beim Flow Classifier optimiert, der Datenströme klassifiziert.

Einige weitere Neuerungen am Netzwerkcode nennt der Kommentar des Git-Merge, der das Gros der Änderungen enthält, die für 5.2 in diesem Bereich vorgenommen wurden.

ISDN4Linux (I4L) soll bei 5.3 rausfliegen; auch der Capi-Stack steht auf der Abschussliste.

Bei Linux 5.3 soll es viel Code für ISDN-Hardware an den Kragen gehen, nachdem die meisten öffentlichen ISDN-Netzwerke laut den Linux-Entwicklern mittlerweile abgeschaltet wurden. Der alte ISDN4Linux-Stack samt seinem früher recht bekannten Hisax-Treiber soll komplett rausfliegen. Der jüngere CAPI-Stack wandert in den Staging-Zweig – der ist als Bereich für Code mit bekannten Qualitätsmängeln gestartet, dient dieser Tage aber gelegentlich auch als Vorstufe für Code, den die Entwickler entfernen wollen. Bisher wollten sie den Capi-Stack nicht absägen, da unklar ist, ob noch jemand diesen Code und seine Treiber mit aktuellen Kerneln nutzt; wer das tut, sollte sich daher baldmöglichst bei den Entwicklern melden, um den Rauswurf vielleicht abzuwenden.

Im Kernel verbleiben soll hingegen der mISDN-Stack, der die meiste Hardware unterstützt, die auch Hisax anspricht; das ist auch der Stack, auf dem die Telefonanlagen- und VoIP-Software Asterisk aufbaut.

Einige weitere Neuerungen rund um Sicherheit nennen die Git-Commit-Kommentare der Subsysteme Audit, Crypto, Random, SELinux, Tomoyo. Vermutlich kurz nach Erscheinen von Linux 5.2 dürfte Linux-Entwickler Kees Cook auch wieder einen Beitrag in seinem Blog veröffentlichen, in dem er regelmäßig einen Überblick zu Sicherheitsverbesserungen neuer Kernel-Versionen liefert. Zuletzt etwa für Linux 5.1. Dort hat er beispielsweise Arbeiten erwähnt, um switch nutzenden Programmcode aufzuräumen, damit der nach einem case-Abschnitt nicht versehentlich auch den folgenden ausführt, weil der Entwickler das Case-Ende-Zeichen vergessen hat. Bei den Aufräumarbeiten zur Vermeidung solcher "implicit fall-through"-Fälle haben die Entwickler schon eine Reihe von Bugs gefunden. Bei 5.2 gab es nochmal deutliche Fortschritte, wodurch die Entwickler jetzt fast alle derartigen Stellen im Kernel-Code tilgen konnten.

Mit Intels Scalable I/O Virtualization soll sich Hardware kleinteiliger an VMs oder Container überstellen lassen.

(Bild: Vortragsfolien )

Die IOMMU-Infrastruktur des Linux-Kernels bietet jetzt "AUX domain support" und unterstützt damit Intels Scalable I/O Virtualization – eine Technik, mit der sich Funktionen von Hardwarekomponenten unter die Kontrolle von virtuellen Maschinen (VMs), Containern oder Prozessen stellen lassen, ohne die Sicherheit des Systems zu gefährden (u. a. 1, 2, 3, 4, 5, 6). Auf diese Weise kann der Kernel etwa virtuelle, vom Netzwerkchip bereitgestellte virtuelle Netzwerkschnittstellen zur freien Verfügung an VMs oder Container überstellen. Für derlei wird bislang meist Single Root I/O Virtualization (SR-IOV) genutzt, das allerdings mehr Overhead hat und unter anderem dadurch nicht hunderte oder gar tausende Sub-Funktionen exportieren kann, wie es heutige hoch-skalierbare Systeme manchmal erfordern. Details zur mit VT-d 3.0 spezifizierten Scalable I/O Virtualization liefern ein Blog-Beitrag und einige Vortragsfolien von Intel-Mitarbeitern. Wie bei SR-IOV muss die Hardware aber auch für Scalable I/O Virtualization ausgelegt sein.

Beim Erzeugen eines neuen Prozesses über den Systemaufruf clone() können Programme mit dem neuen Syscall-Flag CLONE_PIDFD jetzt gleich den seit Linux 5.1 unterstützten PID File Descriptor (PIDFD) erhalten, der auf den neu erstellten Prozess verweist. Die neue Funktion ist unter anderem für System-Management-Werkzeuge gedacht, die mit diesem File Descriptor hundertprozentig sicher gehen können, dass sie später an diesen Prozess gesendete Signale nicht versehentlich an einen anderen, vollkommen unbeteiligten Prozess schicken. Details zu dem Feature, das die Android- und Systemd-Entwickler nutzen wollen, erläutert der LWN.net-Artikel "Rethinking race-free process signaling".

Die zweite Generation der Control Groups (Cgroups v2) bringt nun auch einen Controller mit, um Prozesse vorübergehend einzufrieren – etwa um derweil in Ruhe einige Ressourcen für den Weiterbetrieb frei schaufeln zu können, falls Überlastung droht. Dieser Freezer ist einer der letzten Controller, die zum kompletten Umstieg auf Cgroup v2 noch fehlten. Im Commit-Kommentar und der Dokumentation weist der zuständige Entwickler indes darauf hin, dass der neue Freezer Controller etwas anders vorgeht als der ältere.

Wie bei jeder neuen Kernel-Version haben die Kernel-Entwickler zahlreiche Optimierungen vorgenommen – die sorgen bei bestimmten Umgebungsbedingungen manchmal für einen größeren Geschwindigkeitsgewinn, können bei anderen Systemen aber nur geringen oder gar keinen Einfluss auf die Performance haben. Unter diesen Optimierungen sind etwa Umbauten am Code zur Speicherplatz-Anforderung via Vmalloc, die Latenzen reduziert und dadurch die Performance deutlich verbessern kann. Durch diese "Improve Vmap Allocation" genannten Änderungen konnte der zuständige Entwickler ein Testprogramm in viereinhalb Minuten ausführen, das auf seinem Einplatinencomputer mit ARM64-Prozessor zuvor nach 24 Stunden noch nicht fertig war.

Eine effizientere Nutzung der Prozessor-Caches verspricht die Patch-Serie "Randomize free memory". Laut dem Entwickler wirkt sich das in vielen Tests nicht sonderlich aus, führt in bestimmte Szenarien aber zu enormen Performance-Gewinnen.

Der Kernel kann jetzt die mit GCC 9 eingeführte Option -flive-patching nutzen, um Optimierungen zu umgehen, die Kernel Live Patching (KLP) verkomplizieren. Laut den Entwicklern schnitten einige Scheduler-Benchmarks durch die neue Option allerdings ein bis drei Prozent schlechter ab.

Unter den wie üblich zahlreichen Änderungen an Infrastruktur und Werkzeugen zum Performance Monitoring mit perf war Support für Adaptive PEBSv4 (Precise Event-Based Sampling), das Intel in neue CPUs verbaut und den Overhead bei Geschwindigkeitsanalysen erheblich reduzieren kann. Ebenfalls neu: Die Perf-Record-Option --mmap-flush=<number>, Unterstützung zur Kompression mit Zstandard (Zstd) sowie Support für Intels-CPUs der Generationen Tremont und Ice Lake.

Für Entwickler wichtig: Die Kernel-Macher haben das mmiowb() genannte Macro für Memory-Mapped I/O (MMIO) entfernt, das allerlei Tücken hatte, die LWN.net im Artikel "Memory-mapped I/O without mysterious macros" erläutert.

Neu dabei ist auch ein Dokument, das einige Performance-Aspekte bei Arbeitsspeicherzugriffen in NUMA-Systemen näher erläutert. Ferner gab es einen ganzen Schwung Änderungen (u. a. 1, 2, 3), um den Support für Heterogenous Memory Management (HMM) zu verbessern – die in Linux 4.14 integrierte Infrastruktur, die die effiziente Nutzung von Zusatzprozessoren wie Crypto-Beschleunigern oder GPUs erleichtert, denen eigener Arbeitsspeicher zur Seite steht.

Die Kommentare der Git-Merges zahlreicher Subsysteme nennen einige weitere wichtige Änderungen – etwa in dem Bereichen ACPI, Dokumentation (1, 2), Cgroup, EFI, Ftrace, Iommu, Kbuild (1, 2), Kgdb, Ktest, Kselftest (1, 2), Locking Core, Livepatching, Objtool, PCI, Percpu, Pidfd, Power Management, Printk, RCU Core, Scheduler, SMP Hotplung, Thermal und VFIO.

Linux 5.2 unterstützt viele Notebooks mit AMD-Ryzen-Prozessoren jetzt besser, etwa das Dell Latitude 5495 oder die Lenovo-Modelle Yoga 530 und Ideapad 530s. Das ist der Aufnahme eines Treibers für AMDs MP2 I2C Controller zu verdanken, denn nur mit einem solchen kann Linux die per I2C angebundenen Touchpads und Touchscreens dieser Notebooks ansprechen.

Apropos AMD: Mit Linux 5.2 können Geräte, die am wichtigsten Kommunikationsbus moderner AMD Prozessoren hängen, direkt Daten austauschen, ohne der CPU sonderlich Arbeit zu machen. Das kann die Performance steigern, denn dieser Peer-to-Peer Direct Memory Access (PCI/P2PDMA) zwischen PCIe-Geräten am Zen Root Complex vermeidet Overhead. Ebenfalls neu: Unterstützung für die zweite Generation der ZEN-Prozessorarchitektur im Treiber für EDAC (Error Detection And Correction).

Unter den Änderungen am Audio-Support waren Infrastruktur und Treiber zur Unterstützung von Sound Open Firmware (SOF) (u. a. 1, 2, 3, 4, 5, 6). Dabei handelt es sich um eine Firmware, die den für die Audio-Ausgabe zuständigen Digital Signal Processor (DSP) antreibt. Solche ist bislang meist proprietär; um das zu ändern, haben Intel und Google das SOF-Projekt im Frühjahr 2018 unter dem Dach der Linux Foundation initiiert. Als Startkapital steuerte Intel eine zuvor proprietäre Firmware für die DSP seiner modernen Prozessor-Plattformen bei und die beiden riefen andere Hersteller auf, bei dem Projekt mitzumachen. Die jetzt beigesteuerten Treiber steuern SOF-taugliche Chips von Intel und Xtensa an.

Eine kleine Änderung an der Stromspartechnik-Konfiguration des Treibers für Realtek-HD-Audio-Codecs verspricht zudem Hintergrundrauschen und Knackgeräusche zu beseitigen, die auf einer Reihe von Geräten auftreten.

Über den neuen Treiber Mt76 unterstützt Linux jetzt auch die 4×4-802.11ac-WLAN-Chips der Mediatek-Reihe MT7615.

Neu dabei ist auch der Treiber Rtw88, der die von Realtek gefertigten 802.11ac-WLAN-Chips RTL8822BE und RTL8822CE anspricht. Beides sind PCIe-Chips; Unterstützung für damit verwandte, aber per USB und SDIO angebundene Chips mit den gleichen Nummern in der Modellbezeichnung fehlt, soll aber bald folgen. Das gilt auch für Patches, die viele andere im Commit-Kommentar erwähnte Funktionslücken und Schwächen beseitigen sollen, die der von Realtek-Entwicklern beigesteuerte Treiber noch aufweist.

Dass der neue Treiber in einem noch unfertigen Zustand aufgenommen wurde, ist bei Linux nicht ungewöhnlich: Auch ein Basistreiber mit vielen fehlenden Features ist für manche Nutzer schon eine große Hilfe. Außerdem ist der Codeumfang dadurch kleiner, was den Kernel-Entwicklern die initiale Begutachtung erleichtert. Das ist gerade bei Treibern von unerfahrenen Linux-Entwicklern wichtig, denn dadurch sind Umbauten leichter, wenn bei so einem "Review" größere Probleme auftauchen. Zudem sind dann auch später folgende Änderungen leichter zu begutachten, die nach und nach Funktionslücken beseitigen.

Ein wenig ungewöhnlich ist indes, das ein Staging-Treiber für eben diese Realtek-Chips bereits rausgeworfen wurde: Der hat zwar viele bekannte Mängel, wäre für den ein oder anderen Nutzer aber womöglich vorerst die bessere Wahl gewesen.

Der neue Kernel unterstützt einige drahtlose Logitech-Mäuse und -Tastaturen (etwa die Modelle MX3000 und MX5000) von jetzt besser; das ist einigen Änderungen (u. a. 1, 2, 3, 4) von Hans de Goede zu verdanken, der in seinem Blog weitere Hintergründe zum Umbau liefert.

Neu dabei sind ein Treiber für das Macally Ikey Keyboard, eine Firmware-Update-Interface für den Intel Integrated Sensor Hub (ISH) und eine Erweiterung, um die Funktionstasten-Sperr-Taste (FN-Lock) neuerer Asus-Notebooks zu unterstützen. Der in Linux vorhandene Code für ChromeOS-Geräte enthält jetzt auch einen Logging-Treiber fürs Laden via USB Power Delivery (PD).

Linux bringt jetzt auch einen Treiber für den U2F Zero – ein USB-Token für die Zweifaktor-Authentifizierung. Laut Beschreibung kann der Treiber aber anscheinend bislang nur die LED blinken lassen und den Zufallsdatengenerator als weitere Entropiequelle einbinden.

Das USB-Type-C-Subsystem unterstützt dank eines neuen Treibers jetzt den VirtualLink bei GeForce-Karten, die eine solche USB-C-Buchse zur Anbindung von VR-Brillen bieten.

Ferner kann das Typ-C-Subsystem nun auch USB Alternate Modes konfigurieren und damit etwa Display-Port-Tunnel einrichten; darüber lässt sich ein Bildschirm mit einem Kabel anbinden, über das USB- und DisplayPort-Daten laufen. Dieser Code ist vornehmlich für Embedded-Systeme gedacht, denn bei PCs kümmert sich meist die Firmware um die grundlegende Einrichtung von Alternate Modes.

Die Thunderbolt-Treiber unterstützen jetzt ältere Apple-Systeme besser, die Thunderbolt-Controller der ersten und zweiten Generation nutzen; dadurch funktionieren dort jetzt Funktionen wie Display-Port-Tunneling, PCIe Daisy Chains und Peer-to-Peer-Netzwerke, denn Linux beherrscht alles Nötige, um derlei bei solchen Systemen selbst zu konfigurieren. Bei den meisten PCs und neueren Macs ging all das schon länger, denn dort kümmert sich meist die Firmware um die grundlegende Einrichtung dieser Dinge.

Die Kernel-Entwickler haben ferner den Cirrus-Treiber generalüberholt, der vergleichsweise simple Grafikchips anspricht, die das oft mit KVM und Xen kombinierte Qemu emulieren kann. Der Treiber konnte dadurch um 70 Prozent schrumpfen, da er jetzt auf viel Basisinfrastruktur des Kernels aufbaut, die in den letzten Jahren für Grafiktreiber geschaffen wurde. Dadurch lernt er zugleich einige für moderne Systeme wichtige Funktionen wie Wayland-Support.

Der Grafiktreiber für den normalerweise von VirtualBox emulierten Grafikchip hat den Staging-Bereich verlassen und ist somit fortan ein regulär gepflegter Treiber. Das ist etwa für Distributionen wichtig, die Code des Staging-Bereichs meiden, weil für ihn Sonderregeln gelten. Dort liegende Treiber erfüllen etwa die normalen Qualitätsansprüche der Linux-Entwickler nicht und können ohne Vorwarnung verschwinden, weil die sonst von Torvalds hochgehaltene Prämisse "keine Regressionen" dort allenfalls eingeschränkt gilt. Während der Zeit im Staging-Bereich wurde der früher extern gewartete Vboxvideo-Treiber enorm verbessert und schrumpfte dabei zugleich erheblich, denn wie der Cirrus-Treiber setzt auch der VirtualBox-Treiber jetzt auf Basisinfrastruktur für Grafiktreiber auf. Durch sie hat er auch an Funktionsumfang zugelegt und beherrscht moderne Features wie das seit Linux 4.12 verstärkt genutzte Atomic Modesetting.

Neu dabei ist der Grafiktreiber Aspeed, der für Linux-Distributionen gedacht ist, die auf dem Aspeed AST2500 laufen. Dabei handelt es sich um einen als Fernwartungs/Sytemmanagement-Controller (Baseboard Management Controller/BMC) arbeitenden SoC (System on Chip), der häufiger auf modernen Serverboards steckt. Der Treiber ist nicht zu verwechseln mit dem schon länger in Linux enthaltenen Grafiktreiber Ast, mit dem der Host ein PCI-Device ansprechen kann, was dieser SoC bereitstellt.

Auch dabei: Änderungen an der Basisinfrastruktur und dem Intel-i915-Treiber, durch die sich der Farbraum jetzt bei jedem Monitoranschluss separat festlegen lässt. Bei Mehrschirmsystemen können Userspace-Anwendungen bei den Monitoren individuell auf Colorspaces wie 601, 709 oder BT2020 umschalten, um so die Darstellungsqualität mit dem erweiterten Farbraum zu verbessern – beispielsweise, wenn ein Video in einem solchen Format encodiert wurde und auf einem Monitor im Vollbild wiedergegeben wird.

Das ist auch für die Linux-Unterstützung zur Ausgabe mit High Dynamic Range (HDR) relevant, an der Intel-Entwickler seit einer Weile arbeiten; einige Grundlagen hierzu sollen in Linux 5.3 einfließen. Bei dieser Version wollen die Entwickler auch Patches nachrüsten, um das eLLC genannte Embedded DRAM (eDRAM) der stärkeren Intel-GPUs seit der Skylake-Generation als Cache nutzen zu können, was die Performance verbessert.

Die im Text erwähnten Neuerungen sind nur die sprichwörtliche Spitze des Eisbergs, denn allein bei den AMD- und Intel-Treibern gab es zahlreiche weitere Änderungen.

(Bild: git.kernel.org – a2d635decbfa )

Der Kommentar des Git-Commit mit dem Gros an Grafiktreiberänderungen nennt noch eine ganze Reihe weiterer Neuerungen rund um den Direct Rendering Manager (DRM) des Kernels und den darauf aufbauenden Grafiktreiber. Durch eine der Änderungen kann man jetzt etwa alte, vermutlich von aktuellen Userspace-Grafiktreiber kaum noch genutzte, Programmierschnittstellen lahmlegen, wodurch das Modul mit den DRM-Kernfunktionen um zehn Prozent kleiner ausfällt.

Der Nouveau-Treiber, der moderne Nvidia-Chips unterstützt, weiß jetzt auch die TU117-GPUs anzusprechen, die etwa bei der GeForce GTX 1650 im Einsatz sind.

Beim für moderne Radeon-GPUs zuständigen Treiber Amdgpu gab es allerlei Feintuning am Freesync-Support, der bei Linux 5.0 zum Kernel stieß und durch dynamische Anpassung der Bildwiederholrate (Variable Refresh Rate/VRR) für flüssige 3D-Darstellung sorgt. Vega-12 und Vega-20-Chips dürften dank besserem Support für BACO (Bus Active, Chip Off) sparsamer laufen. Neu dabei ist experimenteller und standardmäßig inaktiver Treibercode für die elfte Generation von AMDs System Management Unit (SMU), die Taktfrequenzen, Spannungen, Power Management, Lüfterregelung und einiges andere steuert. Dieser noch junge Treibercode, der nur die SMU von Vega20-GPUs unterstützt, soll den PowerPlay-Code ersetzen, der bislang solche Aufgaben regelt. Das sind Vorarbeiten zur Unterstützung der neuen Grafikprozessor-Generation "Navi", die AMD am 7. Juli mit der Radeon RX 5700 und 5700 XT vorgetellt hat. Derzeit deutet einiges darauf hin, dass die Unterstützung für diese Grafikprozessoren in das Mitte September erwartete Linux 5.3 einziehen wird (u. a. 1, 2). Bis dahin dürfte dann auch Mesa 19.2 mitsamt einem deutlich erweiterten OpenGL-Treiber und einem verbesserten Vulkan-Treiber Radv erhätlich sein, die auf den DRM-Treiber von Linux 5.3 aufbauen und eine Nutzung der 3D-Beschleunigung von Navi-GPUs ermöglichen werden.

Erstmals im Lieferumfang ist auch das Generic Counter Interface, mit dem sich einige im Industrieumfeld gelegentlich eingesetzte Zähler-Hardware ansprechen lässt (u. a. 1, 2).

Ebenfalls für den Industrieeinsatz von Interesse: Unterstützung für die Fieldbus genannte Familie von Kommunikationsprotokollen sowie die darauf aufbauenden Treiber für HMS Anybus-S Bus und HMS Profinet IRT. Der Fieldbus-Support hat aber Mängel und ist im Staging-Bereich gelandet. Dort gelten die Garantien nicht, die es sonst für Kernel-Code gibt, daher sind Regressionen dort nicht tabu – im dümmsten Fall kann es daher sogar passieren, dass der Code in ein paar Monaten oder Jahren wieder rausfliegt, obowhl er Nutzer hat.

Durch die erwähnten und zahlreiche weitere Änderungen unterstützt Linux 5.2 über 450 Geräte oder Geräteklassen mehr als sein Vorgänger; bei knapp hundert davon handelt es sich um PCI/PCIe-Geräte, wie die Datenbanken der Linux Kernel Driver DataBase (LKDDb) zeigen. Details zu diesen und zahlreichen weiteren Neuerungen rund um Treiber finden sich in den Kommentaren der wichtigsten Git-Merges in den Subsystemen Char, Driver-Core, Fbdev, HID, Hwmon, Input, LEDs, Media, Platform Chrome, Platform x86, RDMA, Staging, USB und Watchdog.

Über Dateien unter Pfaden wie /sys/devices/system/cpu/cpu0/power/energy_perf_bias kann man jetzt den Intel Energy and Performance Bias Hint (EPB) abfragen und setzen. Dieser Wert beeinflusst bei EBP-tauglichen Prozessoren, ob der Prozessor im Zweifel zu bestmöglicher Performance oder möglichst geringem Stromverbrauch tendiert, wenn er die Betriebsgeschwindigkeit wählt. Diese Entscheidung der CPU zu überlassen ist für PC-Prozessoren die typischerweise beste Herangehensweise, denn die früher übliche Steuerung über Userspace-Programme ist zu träge und hat nicht so viel EInblick in CPU-Interna.

Linux 5.2 bringt Unterstützung für weitere SoC-Prozessoren und zahlreiche Einplatinencomputer.

(Bild: git.kernel.org – e8a1d7011711 )

Auch beim Support für CPU-Architekturen und SOCs (System-on-a-Chip) gab es allerlei Neuerungen, durch die der Kernel nun etwa den i.MX8M Mini oder Intel's Agilex SoCFPGA Platform anzusprechen weiß. Eine Optimierung am Code zum Restaurieren des Status von Gleitkommaeinheiten (Floating-Point Units/FPUs) von x86-Prozessoren verspricht zudem die Performance zu verbessern, denn das passiert nach Möglichkeit jetzt nicht mehr bei jedem Context Switch, sondern nur beim Wechsel zurück zu Userspace. Eine Detailoptimierung am Support für Microsofts Hyper-V kann in manchen Situationen nun zu einem kleinen Performance-Gewinn führen.

Unter den jetzt unterstützten Single-Board-Computern sind unter anderem der FriendlyElec NanoPi NEO4, das Nvidia Jetson Nano Developer Kit, Orange Pi RK3399 Board, Zii Ultra akka RDU3. Weitere Änderungen aus den Bereichen Architektur, SOCs und Virtualisierung nennen die Git-Merges zu Bereichen wie ARM-SOC, ARM-SOC-Drivers, ARM-SOC-DT, ARM64, Csky, ARM, KVM, M68K, MIPS, Parisc, Powerpc, RISC-V, S390 (1, 2), Sparc, x86 (IRQ, Kdump, Microcode, MM, Platform, Topology) und Xtensa

Wie jüngst üblich bringt auch Linux 5.2 wieder einen ganzen Schwung an Verbesserungen rund um die BPF Virtual Machine, auf die mittlerweile zahlreiche Subsysteme des Kernels für verschiedenste Aufgaben zurückgreifen – allen voran für Performance-Analysen, die Ablaufverfolgung (Tracing), das Seccomp-Sandboxing und den Netzwerk-Schnellverarbeitungspfad eXpress Data Patch (XDP).

Für Performance-Analysen, Ablaufverfolgung oder Debugging wichtige Daten wie Header lassen sich jetzt nicht mehr nur im etablierten DWARF-Format hinterlegen, sondern auch mit dem bei Linux 4.18 eingeführten BPF Type Format (BTF). Hauptvorteil des neuen Ansatzes ist geringerer Speicherbedarf: Zum Hinterlegen der C-Typen eines Kernel-Images (vmlinux) soll BTF zehnmal weniger Speicherkapazität benötigen. Das gelingt unter anderem durch Deduplizierung, mit dem der Platzbedarf bei anderen Einsatzzwecken sogar um hundertmal kleiner ausfällt als beim verbreiteten DWARF.

Das soll weitere Einsatzgebiete ermöglichen, denn durch den geringeren Overhead wird es für Distributoren attraktiver, diese Daten in Kernel und Modulen zu belassen, statt sie auszulagern oder komplett zu ignorieren. Ein Linux-Image wird dann selbstbeschreibend ("self-descriptive"). Das ist etwa interessant, damit Tracing-Programme wie perf, bpftrace oder Werkzeuge der BPF Compiler Collection (BCC) alle für ihre Tätigkeiten nötigen Informationen auf jedem System vorfinden und leicht zur Hand haben. Bislang muss man dazu meist Debuginfo-Pakete nachinstallieren, falls der Distributor denn an dieses Nutzungsszenario gedacht hat und solche denn auch bereitstellt.

Durch den neuen Support für "Global Data" in BPF beherrschen BPF-Programme jetzt globale Variablen, wie sie C bietet. Hauptziel der Erweiterung: Ein Programm-Binary nachträglich anpassen zu können, damit man BPF-Programme nicht immer wieder neu kompilieren muss, wenn sich ein Konfigurationsdetail ändert.

Bislang muss man BPF-Programme nämlich oft genau für den jeweiligen Einsatzzweck übersetzen, denn bei BPF-Programmen zur Handhabung von Netzwerkpaketen werden beispielsweise Daten wie IP- oder MAC-Adressen im Code definiert. Durch Global-Data-Support lassen sich solche Variablen jetzt nachträglich in der Binärdatei ändern. Ein einmal kompiliertes Programm kann so als "Template Binary" fungieren, das Entwickler oder Werkzeuge wie die Container-Netzwerksoftware Cilium nachträglich verändern, wenn das Programm später andere IP- oder MAC-Adressen nutzen soll.

Das Ganze gelingt mithilfe des bereits erwähnten BTF, mit dem die globalen Daten im Kompilat hinterlegt werden. Solche "compile-once"-Programmvorlagen ermöglichen schneller einsatzbereite BPF-Programme, da man diese nicht mehr ad-hoc individuell kompilieren muss; neben Zeit spart das Ganze somit auch CPU-Ressourcen und funktioniert auch auf Systemen ohne Compiler.

Der BPF Verifier, der von der BPF Virtual Machine ausgeführten Code vor der Ausführung überprüft, akzeptiert jetzt komplexeren Code: Bislang durfte ein Programm 4096 Instruktionen aufweisen und bei der Ablaufsimulation maximal 130.000 Instruktionen ausführen (etwa durch If-Verzweigungen). Jetzt ist in beiden Fällen bei 1.000.000 Instruktionen Schluss. Das alte Limit konnte angehoben werden, weil die Entwickler einige "BPF Verifier Scalability" genannte Optimierungen vorgenommen haben, die die Prüfung um ungefähr das Zwanzigfache beschleunigen.

Darüber hinaus gab es noch allerlei andere Umbauten an oder rund um die BPF Virtual Machine (u. a. 1, 2, 3, 4, 5). Unter denen ist beispielsweise auch noch das BPF SK Local Storage, das die Netzwerkprogrammierung mit BPF erleichtern soll, oder der TCP-Syncookie-Check, der die Programmierung von Loadbalancern in der Art von Glb-Director oder Beamer mittels BPF ermöglichen soll.

Support für die viel Aufsehen erregende VPN-Technik WireGuard fehlt Linux 5.2 – kein Wunder, denn bei den Integrationsbemühungen gab es jüngst so gut wie keine Fortschritte. Berichten zufolge sollen diese jetzt aber wieder verstärkt werden, nachdem die Entwickler der VPN-Technik im Mai eine Pre-Alpha-Version von WireGuard für Windows veröffentlicht haben. Dass der Wireguard-Support in Linux 5.3 einzieht, scheint allerdings äußerst unwahrscheinlich: Zur Freigabe von Linux 5.2 sollten alle größeren Änderungen für 5.3 bereits begutachtet sein, was nicht der Fall ist.

Mit der Freigabe von Linux 5.2 beginnt zugleich die "Merge Window" genannte Phase, in der Linus Torvalds das Gros der Änderungen für den Nachfolger integriert. In den nächsten Tagen fließen daher viele tausend Änderungen in den Hauptentwicklungszweig von Linux ein, die Entwickler in den letzten Wochen zur Aufnahme in 5.3 vorbereitet und gesammelt haben.

Linus Torvalds beendet das Merge Window typischerweise nach zwei Wochen, indem er die erste Vorabversion einer neuen Kernel-Version veröffentlicht. Das läutet zugleich die Stabilisierungsphase ein, die derzeit fast immer sieben oder acht Wochen dauert. Linux 5.3 erscheint daher wahrscheinlich am 9. oder 16. September.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne
Doku)²
Entwick-
lungs-
zeitraum
Commits
(Ohne
Merges)³
Diffstat⁴
Linux 4.14 61.290 25.041.284
(23.050.486)
70 Tage 14.659
(13.452)
23.388 files changed,
 719.862 insertions(+),
 445.585 deletions(-)
Linux 4.15 62.303 25.364.802
(23.329.451)
77 Tage 16.223
(14.866)
13.265 files changed,
 643.912 insertions(+),
 320.289 deletions(-)
Linux 4.16 62.915 25.558.805
(23.495.643)
63 Tage 14.896
(13.630)
12.239 files changed,
 1.133.069 insertions(+),
 939.066 deletions(-)
Linux 4.17 61.362 25.379.564
(23.314.368)
63 Tage 14.745
(13.541)
14.504 files changed,
 777.301 insertions(+),
 956.941 deletions(-)
Linux 4.18 61.003 25.280.872
(23.183.236)
70 Tage 14.432
(13.283)
13.141 files changed,
 583.336 insertions(+),
 682.028 deletions(-)
Linux 4.19 61.734 25.588.455
(23.449.221)
70 Tage 15.204
(14.043)
11,693 files changed,
 552.223 insertions(+),
 244.235 deletions(-)
Linux 4.20 62.481 25.955.520
(23.776.585)
63 Tage 14.995
(13.844)
11402 files changed,
 685.027 insertions(+),
 317.959 deletions(-)
Linux 5.0 63.135 26.203.035
(23.933.016)
70 Tage 13.921
(12.808)
12.100 files changed,
579.084 insertions(+),
331.570 deletions(-)
Linux 5.1 63.873 26.459.776
(24.141.004)
63 Tage 14.160
(13.034)
11.977 files changed,
 545.423 insertions(+),
 288.683 deletions(-)
Linux 5.2 64.587 26.552.127
(24.175.296)
63 Tage 15.089
(14.024)
30.888 files changed,
 624.857 insertions(+),
 532.510 deletions(-)
¹ git ls-tree -r --name-only HEAD | wc -l
² find . -type f -not -regex '\./\.git/.*' | xargs cat | wc -l; echo "($(find . -name *.[hcS] -not -regex '\./\.git/.*' | xargs cat | wc -l))"
³ git-log --pretty=oneline vx.(y-1)..vx.(y) | wc -l; echo "($(git-log --pretty=oneline --no-merges vx.(y-1)..vx.(y) | wc -l))"
⁴ git diff --shortstat vx.(y-1)..vx.(y)

Mehr Infos

Den neuen Linux-Kernel herunterladen und einrichten

Direkt nach der Freigabe steht die neue Linux-Version nur über einen Git-Checkout des "Mainline" genannten Hauptenwicklerzweigs bereit; die Download-Möglichkeit über die Frontseite von Kernel.org folgt meist erst einige Stunden später, wenn sich die Büros in Europa richtig füllen.

Auf dem Server der Linux-Entwickler finden Sie eine Anleitung, wie Sie die Authentizität und die Unversehrtheit des Quelltextes prüfen; dort gibt es auch ein Skript, das eine Version herunterlädt und diese Aufgaben durchführt.

Fedora und Rolling-Release-Distributionen wie Arch Linux, Gentoo und OpenSuse Tumbleweed erhalten die neue Linux-Version in den nächsten Tagen und Wochen im Rahmen der regulären Systemaktualisierung. Bei bereits erhältlichen oder kurz vor der Veröffentlichung stehende Releases von Debian, OpenSuse Leap, Ubuntu und den meisten anderen klassisch gewarteten Distributionen macht der Kernel normalerweise keine größeren Versionssprünge; deutlich neuere Linux-Versionen erhält man dort meist nur beim Wechsel auf eine neuere Version der Distribution.

Einzelne Distributionen werden den neuen Kernel über Backports-Repositories zur einfachen Installation anbieten. In der Regel sind solche aber standardmäßig inaktiv, weil dort andere Pflegerichtlinien gelten; Sicherheitskorrekturen beispielsweise werden dort vielfach nicht garantiert, auch wenn es sie meist zeitnah gibt.

Bei vielen populären Distributionen wird kann man neue Linux-Versionen auch Kernel-Pakete in Repositories nachrüsten können, die Fans oder Entwickler pflegen. Anwender sollten sich bewusst sein, dass sie über solche Angebote zentrale Bausteine ihrer Distribution austauschen. Wer solche Repositories verwendet, sollte deren Anbietern ähnlich trauen wie seinem Distributor, denn über darin liegende Pakete lassen sich kinderleicht Hintertüren einschleusen. Nach dem Einbinden solcher Repositories obliegt es zudem den Machern dieser Depots, die ausgetauschten Pakete fortan mit Sicherheitskorrekturen zu versorgen. Das vorübergehende oder dauerhafte Aktivieren solcher Repositories kann zudem zu Abhängigkeitsproblemen bei späteren Updates der Distribution führen. Da zentrale Software ausgetauscht wird, kann es zudem leicht zu Instabilitäten kommen; im dümmsten Fall starte das ganze System nicht mehr.

Wer die neue Linux-Version eigenhändig kompilieren und einrichten will, finden Hinweise dazu im c't-Artikel "Linux-Kernel maßgeschneidert". Das darin beschriebene Make-Target make localmodconfig erzeugt weitgehend automatisch eine recht gut auf das jeweilige System zugeschnittene Kernel-Konfiguration, mit der Sie in wenigen Minuten eine neue Linux-Version einrichten können.

Allerlei weitere Informationen zu Linux liefern der erste, zweite und dritte Teil einer c't-FAQ-Reihe mit "Basiswissen zum Linux-Kernel".

Mehr Infos

Versionshistorie dieses Artikels

  • 2019-07-08, 6:30 – v2.0: Kurzüberblick am Anfang eingefügt und Textinhalte umgestellt, um die interessantesten Neuerungen vorne zu beschreiben.
  • 2019-07-02, 6:30 – v1.5: Neue und verbesserte Treiber erläutert; Highlights-Abschnitt damit leer und entfernt; damit ist der Überblick zu den Neuerungen von Linux 5.2 nach aktuellem Stand komplett.
  • 2019-06-28, 6:30 – v1.4: Neuerungen rund um Sicherheit und Netzwerk-Support beschrieben.
  • 2019-06-25, 6:30 – v1.3: Änderungen bei Dateisystemen und Storage-Support erläutert.
  • 2019-06-24, 9:30 – v1.2.2: SPDX-Abschnitte leicht angepasst, da noch ein Schwung Änderungen gefolgt ist. Außerdem Abschnitt zu Navi-Support konkretisiert, nachdem die Patches jetzt verfügbar sind.
  • 2019-06-18, 6:30 – v1.2: Änderungen an der Infrastruktur beschrieben.
  • 2019-06-04, 14:30 – v1.1.1: Deutlicher gemacht, dass die IDE/PATA-Treiber auf Libata-Basis im Kernel bleiben.
  • 2019-06-04, 06:30 – v1.1: Neuerungen bei Grafiktreibern eingefügt, Lima und Panfrost aber ausgespart.
  • 2019-05-20, 06:55 – v1.0: Erstpublikation anlässlich von 5.2-rc1, die nur die Highlights dieser Linux-Version nennt.

Der Newsticker von heise online erwähnt alle größeren Texterweiterungen, auf die auch der Twitter-Account @kernellog hinweist.

(thl)