Linux 5.3 freigegeben: Prioritäten deckeln und Trouble für Nvidia

Der neue Kernel schaufelt 16 Millionen weitere IPv4-Adressen frei, indem er ein Relikt ad acta legt. Den ISDN-Support stutzen die Entwickler zusammen. Zum Ausgleich bekommt Linux eine Funktion für Zeitreisen.

Lesezeit: 29 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 536 Beiträge
Linux Kernel 5.3
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Linus Torvalds hat zum Wochenstart den Linux-Kernel 5.3 freigegeben. Wie jede neue Version der Hauptentwicklungslinie von Linux bringt auch die neueste weit über zehntausend Änderungen. Einige rüsten neue Features nach, andere verbessern existierende. Die wichtigsten dieser Neuerungen im Kurzüberblick, bevor der Text in die Details geht:

  • Admins oder Entwickler können einzelne Programme jetzt speziell auszeichnen, um deren Reaktionsfreude zu steigern; alternativ kann man damit auch die Leistungsaufnahme des Systems reduzieren.
  • Weil es bei älteren AMD-CPUs ein bekanntes Problem bei der Zufallszahlenanforderung per RDRAND() gibt, versteckt der Kernel fortan die Verfügbarkeit dieser x86-Instruktion.
Das Kernel-Log
  • Nvidias proprietäre Linux-Treiber dürften auf Systemen mit Power-Architektur nicht mehr rund laufen. Das passiert zufällig zu einer Zeit, in der sich Nvidia der Open-Source-Gemeinde zumindest ein klein wenig weiter zu öffnet; wie stark und wie weit, muss sich noch zeigen.
  • Linux 5.3 unterstützt AMDs neue Grafikchip-Generation Navi10, die im Juli mit der Radeon RX-5700-Serie debütierte. Support für weitere Navi-GPUs soll bei Linux 5.4 folgen.
  • Die neue "Zeitreisen"-Funktion kann automatisierte Tests beschleunigen.
  • Das vor allem für Firewalls verwendete Netfilter-Subsystem kann einige Arbeiten jetzt an entsprechend taugliche Hardware delegieren.
  • Linux 5.3 unterstützt IPv4-Adressen aus dem Bereich 0.0.0.0/8 und macht so rund 16 Millionen weitere Adressen verfügbar.
  • Die Entwickler haben zwei von drei ISDN-Infrastrukturen des Kernels entfernt.
  • Linux läuft jetzt auch auf der x86-Prozessorarchitektur der chinesischen Firma Zhaoxin.
  • Dank vieler neuer und überarbeiteter Treiber wird Linux 5.3 den Hardware-Support wieder verbessern. Dadurch laufen etwa Asus-Gaming-Notebooks der TUF-Reihe jetzt besser mit Linux. Bei einigen Einplatinencomputern mit Allwinner-Chip lässt sich das Decodieren von H.264-Videos nun an die Hardware delegieren. Bei neueren Macs funktionieren jetzt Tastaturen und Touchpads unter Linux. Und Intels Grafiktreiber beherrscht jetzt die Bildschirm-Ansteuerung mit HDR (High Dynamic Range).
  • Um Plattenplatz zu sparen, dürfen jetzt die Firmware-Dateien gepackt vorliegen, die viele Treiber bei der Hardware-Initialiserung brauchen.
  • Beim Schreiben von Programmen für die BPF Virtual Machine des Kernels können Entwickler jetzt Schleifen verwenden, wie man es aus anderen Programmiersprachen kennt.
  • Durch Aufnahme einer kleinen Änderung hat Linus Torvalds signalisiert, in nächster Zeit die im Realtime-Zweig (RT-Tree) entwickelten Änderungen aufnehmen zu wollen, die Linux zu Echtzeitfähigkeiten verhelfen.

Die folgenden Absätze und Artikelseiten liefern zahlreiche wichtige Details zu diesen und zahlreichen weiteren Neuerungen von Linux 5.3.

Nvidias proprietäre Linux-Treiber laufen auf Systemen mit Power-Architektur nicht mehr, weil die Linux-Entwickler einige von den Treibern bislang genutzte Andockpunkte entfernt haben (u. a. 1, 2, 3, 4). Das erfolgte bei Aufräumarbeiten, denn einem Entwickler war aufgefallen, dass der im Kernel enthaltene Code diese Modul-Exporte gar nicht benötigt. Dass Nvidias proprietärer Grafiktreiber für Power-Systeme dort andockte, hat die Linux-Entwickler nicht von den Aufräumarbeiten absehen lassen: Aus ihrer Sicht geht es um eine Kernel-interne Schnittstelle und eben nicht um ein Userspace-API, bei dem dergleichen tabu wäre.

Greg Kroah-Hartman unterstrich: Bei Aufräumarbeiten wird keine Rücksicht auf externe Treiber genommen.

(Bild: LKML-Archiv )

Bei in der Diskussion um die Entfernung schalten die Entwickler sogar Greg Kroah-Hartman ein, der als zweitwichtigster Linux-Entwickler gilt und sinngemäß schrieb: Nicht im offiziellen Linux-Kernel enthaltene Treiber sind [bei solch einer Entfernung/Entscheidung] nicht relevant. Nvidia muss daher jetzt sehen, wie es ohne die Eingriffspunkte auskommt, wodurch sich die Performance von Tesla-Beschleunigern in Power-Systemen für HPC (High Performance Computing) verschlechtern könnte.

Mehr Infos

Bessert sich Nvidia?

Nvidia öffnet sich ein wenig: Die Firma hat kürzlich Details zur Programmierung aktueller Grafikchipgenerationen unter einer Open-Source-Lizenz auf Github veröffentlicht. Das erleichtert Open-Source-Entwicklern die Arbeit, auch wenn wichtige Informationen erst noch folgen sollen.

Bislang hat Nvidia bei Open-Source-Entwicklern einen eher schlechten Ruf. Kein Wunder, denn anders als AMD und Intel treibt das Unternehmen quelloffene Linux-Treiber für seine PC-Grafikchips nicht selbst voran. Das Unternehmen hilft auch sonst nur unwesentlich und hat bislang Details zur Treiberprogrammierung wie Staatsgeheimnisse gehandhabt. Linux-Entwickler müssen daher viel mit Reverse Engineering arbeiten, was einer der Hauptgründe ist, warum die von Distributionen standardmäßig eingerichteten Kernel- und OpenGL-Treiber "Nouveau" viele Schwächen haben; sie machen beispielsweise nur einen Teil der 3D-Leistung locker und unterstützen längst nicht alle Funktionen der GeForce-Chips.

Letztlich ist aber mehr nötig, bevor sich diese problematische Situation signifikant verbessern kann. Für ordentliche Open-Source-Treiber wäre es nämlich auch wichtig, den Linux- Distributoren endlich eine bessere Firmware an die Hand zu geben: Die derzeit von Nvidia bereitgestellte ist eher eine Krücke, denn mit ihr können Grafikchips weder in die sparsamsten noch die schnellsten Betriebsmodi schalten. Das ist derzeit der Hauptgrund, warum die Leistungsaufnahme vieler moderner GeForce-GPUs mit dem Nouveau-Treiber oft höher ist als mit dem proprietären Treiber, die 3D-Performance zugleich aber deutlich schlechter.

Die neue Linux-Version macht rund 16 Millionen weitere IPv4-Adressen verfügbar, denn sie gibt den Adressabschnitt 0.0.0.0/8 zur Nutzung frei. Diesen Block haben die Kernel-Entwickler schon seit der Frühzeit von Linux bewusst ausgespart, denn einige BSD-Varianten konnten solche Adressen vor über dreißig Jahren nicht richtig handhaben. Bis sich IPv4-Adressen aus diesem Bereich im Alltag störungsfrei nutzen lassen, dürften aber einige Jahre vergehen, schließlich müssen dazu alle bei der Kommunikation involvierten Systeme sie behandeln können.

Das vor allem für Firewalls verwendete Netfilter-Subsystem ist nun in der Lage, einige Aufgaben an entsprechend taugliche Netzwerkchips zu delegieren; das kann den Hauptprozessor entlasten und so die Performance steigern.

Der Code zur Netzwerkverkehrssteuerung per TC (Traffic Control) kann Pakete jetzt durch das Connection-Tracking-Modul schleusen, um so neue und bestehende Verbindungen zu erkennen. Mit diesem Wissen lassen sich die Daten dann gezielter weiterleiten und so Overhead vermeiden. Auch der Bridge-Code beherrscht jetzt Connection Tracking; dieser Ansatz soll besser funktionieren als die Emulationsschicht "br_netfilter", die Nutzer bislang oft für "Stateful Filtering" heranziehen.

Der Commit-Kommentar nennt mehrere Gründe, warum es dem ISDN-Support jetzt an den Kragen geht.

(Bild: git.kernel.org – 8a7e8ff8ce8a )

Entfernt haben die Entwickler den ISDN4Linux-Stack samt seines früher recht bekannten ISDN-Treibers Hisax. In der Begründung heißt es unter anderem: Der Code werde schon länger nicht mehr betreut und die meisten öffentlichen ISDN-Netzwerke seien mittlerweile abgeschaltet. Den jüngeren CAPI-Stack haben die Entwickler in den Staging-Bereich verlagert, denn auch er soll rausfliegen, wenn Nutzer nicht Einspruch erheben.

Bleiberecht hat hingegen der moderne mISDN-Stack, den die Telefonanlagen- und VoIP-Software Asterisk nutzt. Er unterstützt viele der Chips, die auch Hisax anzusprechen wusste.

Die bislang extern im "RT-Tree" gepflegten Änderungen, die aus Linux einen Realtime-Kernel machen, sollen bald in den offiziellen Kernel einfließen. Das gilt mit Linux 5.3 als sicher, nachdem Entwickler vor knapp 15 Jahren erste Patches mit diesem Ziel veröffentlicht haben. Damals mussten sie noch Spott von Linus Torvalds ertragen, denn es erschien unstemmbar viel Aufwand, Echtzeitfähigkeiten sauber in Linux einzubauen; daher war immer unklar, ob je alle Realtime-Patches in den offiziellen Kernel umziehen würden.

Die Entwickler ließen sich davon nicht beirren lassen und schufen mit dem RT-Tree schon bald einen Linux-basierten Realtime-Kernel, der Anklang bei Unternehmen fand. Diese setzen ihn etwa bei Robotern oder der Maschinensteuerung ein: Echtzeitfähigkeiten sind dort gefragt, um bestimmte Aufgaben immer in einer vorher festgelegten Zeitspanne auszuführen – also auch, wenn irgendetwas anderes das System gerade immens fordert. Dazu braucht es unter anderem Reaktionszeiten im unteren Millisekundenbereich, die Linux durch die RT-Patches garantierten kann.

Viele Verbesserungen, die für den RT-Tree entstanden, zogen über die Jahre bereits in den offiziellen Kernel um, weil sie Linux auch für andere Einsatzgebiete attraktiver machten. Unter die Änderungen waren immer mal wieder auch größere Umbauten, die Torvalds erst strikt und lautstark abgelehnt hatte, wenig später dann aber doch ohne Murren akzeptierte. Der RT-Tree enthält dadurch heute gar nicht mehr besonders viele Patches, dafür aber einige kontroverse – teilweise, weil sie zentrale und daher kritische Infrastruktur des Linux-Kernels betreffen, bei der die Entwickler besondere Vorsicht walten lassen.

Die neue Option zum Bau eines Realtime-Kernels zeigt sich bislang noch nicht, denn sie soll vor allem eines haben: Signalwirkung.

(Bild: c't/Thorsten Leemhuis)

Für Linux 5.3 hat Linus Torvalds eine Änderung in den offiziellen Kernel integriert, die seit den Anfangstagen im RT-Zweigs stecken und ihn quasi definiert: Den kleinen, aber zentralen Patch, der die Konfigurationsoption CONFIG_PREEMPT_RT nachrüstet – also die Einstellmöglichkeit, um beim Kernel-Bau festlegen zu können, ob das resultierende Kernel-Image denn Realtime-Fähigkeiten bieten soll. Diese Option für einen "Fully Preemptible Kernel (Real-Time/RT)" zeigt sich aber vorerst nicht, denn dazu müssen noch weitere Änderungen aus dem RT-Tree folgen. Die Aufnahme richtet sich nämlich vor allem an Kernel-Entwickler, denen die Änderung signalisieren soll: Sperrt euch nicht grundlos gegen die Aufnahme der verbliebenen RT-Patches, denn Linus Torvalds steht dieser Tage voll hinter der Idee, Realtime-Support in den offiziellen Linux-Kernel einzubauen.

Wie schnell das jetzt gelingt, bleibt abzuwarten. Im Herbst 2018 hatten die RT-Entwickler noch verkündet, alle wesentliche Änderungen im Jahr 2019 in den offiziellen Linux-Kernel zu überführen. Mittlerweile wirkt dieses Ziel äußerst ambitioniert. Die Entwickler ließen aber kürzlich durchblicken: Wenn alles gut geht fließen alle wesentlichen Änderungen schon in Linux 5.5 ein, das Ende Januar erscheinen dürfte.

Für Heimnutzer und Server-Admins ist die Echtzeitfähigkeit von Linux indes nur bedingt relevant: Für Realtime-Support ausgelegte Kernel-Images reagieren zwar zackiger, schneiden aber genau wegen der größeren Reaktionsfreude oft schlechter in Durchsatztests ab. Bei Debian, Fedora, Ubuntu & Co. werden sich Realtime-Funktionen daher wohl nur in optionalen Kernel-Images finden, nicht aber in den standardmäßig verwendeten.

Mehr Infos

Dies war ein schrittweise aktualisierter Artikel

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen in Linux 5.3 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.

Über das "Scheduler Utilization Clamping" (Uclamp) können Admins oder Entwickler jetzt einzelne Programme speziell auszeichnen, um deren Reaktionsfreude zu steigern oder die Leistungsaufnahme im Zaum zu halten. Letztlich kann man über die neue Funktion einen Prozess, der den Hauptprozessor wenig belastet, so kennzeichnen, als würde er die CPU stärker fordern. Dadurch steigt die Chance, dass der Scheduler den Prozess an einen schnellen Prozessorkern schickt In anderen Fällen kann es den Kernel auch dazu bewegen, die Taktfrequenz des zuständigen CPU-Cores zeitnah zu steigern. Der Prozess erledigt die Arbeit dann zackiger, wodurch sich das System schneller und interaktiver anfühlt. Google denkt offenbar darüber nach, die Funktion bei Android einzusetzen.

Weniger wichtige, aber CPU-hungrige Prozesse lassen sich via Uclamp auch so kennzeichnen, als würden sie den Prozessor weniger nutzen, als sie es tatsächlich tun. Dadurch versucht der Kernel die Arbeit dann mit einem Prozessorkern auszuführen, der generell besonders sparsam arbeitet; alternativ kann er sich auch entscheiden, den Prozessor vom schnellsten in einen möglichst effizienten Betriebsmodus zu schalten.

Über normale Prioritäten lässt sich Vergleichbares oft nicht erreichen: Diese wirken sich nur bedingt auf die Wahl von Prozessorkern und deren Betriebszustand aus, denn dabei spielen andere Faktoren eine größere Rolle. Vor allem vom Kernel per Load Tracking erfasste Daten, durch die er weiß, wie lange und stark ein Prozess die CPU typischerweise nutzt. Durch sie führt der Kernel einfache und typischerweise nur kurz laufende Prozesse eher mit langsameren CPU-Kernen aus, obwohl es für das Interaktivitätsgefühl besser wäre, wenn er sie einem schnelleren Kern zuteilen würde.

Einstellbar sind die Clamping-Werte über den Syscall sched_setattr(). Patches, um die Werte auch bei Control Groups (Cgroups) festlegen zu können, sind noch in Arbeit. Weitere Details zum Ganzen liefern die Kommentare einiger Uclamp-Patches (1, 2, 3, 4, 6, 7, 8, 9, 10) sowie der ein Jahr alte LWN.net-Artikel "Scheduler utilization clamping".

Distributoren und Nutzer können Firmwaredateien jetzt per xz -C crc32 komprimieren, denn Linux 5.3 kann so gepackte Dateien beim Laden selbst entpacken. Damit lässt sich der Speicherplatz für die Firmware reduzieren, ohne die viele Treiber die jeweilige Hardware nicht initialisieren können. Durch das Packen konnte der zuständige Entwickler den für Firmware-Dateien benötigten Speicherplatz auf seinem System von 419 auf 130 MByte reduzieren.

Durch den Zeitreisen-Modus kann die Uhr in User Mode Linux langsamer oder schneller laufen.

(Bild: Screenshot von git.kernel.org – 065038706f77 )

User Mode Linux (UML), mit dem Linux als regulärer Prozess unter einem anderen Linux laufen kann, bietet jetzt eine "Zeitreisen"-Funktion – allerdings keine echte, denn durch den neuen "Time Travel Mode" kann die Uhr in einer UML-Umgebungen nur langsamer oder schneller als in Wirklichkeit laufen. Das Feature stammt von einem Entwickler, der damit Tests von Zeitüberschreitungen zügiger durchführen möchte. Die automatischen Tests für die Access-Point-Software Hostap wissen den Time Travel Mode bereits zu nutzen (1, 2, 3).

Gerade Systeme mit vielen Prozessorkernen sollen von einigen Änderungen profitieren, die Performance und Fairness der an vielen Stellen des Kernels genutzten Reader Writer Semaphores (rwsem) erheblich verbessern (u. a. 1, 2, 3, 4, 5, 6, 6). Laut den Commit-Kommentaren legen einige Benchmarks, mit denen der Entwickler gezielt die Vorteile der Patches zeigen will, durch die Umbauten um eine Größenordnung zu; einzelne Tests sogar um zwei.

Linux unterstützt jetzt auch die mit PCIe 5.0 definierte Übertragungsgeschwindigkeit mit 32 GT/s.

Linux versteckt den Zufallszahlengenerator älterer AMD-Prozessoren, denn auf einzelnen Boards arbeitet er nach den Suspend fehlerhaft.

(Bild: git.kernel.org – c49a0a80137c )

Bei AMD-CPUs der älteren Familien 15h (Bulldozer) und 16h (Jaguar) versteckt Linux in /proc/cpuinfo nun die Unterstützung für die x86-Instruktion RDRAND(), über die Programme Zufallszahlen anfordern können. Viele Programme nutzen den Zufallszahlenzahlengenerator dadurch nicht mehr, obwohl sie es prinzipiell könnten. Mit der Zufallszahlen-Problematik der Ryzen-3000-CPUs, die jüngst Aufmerksamkeit erregte, hat das Ganze indes so gut wie nichts zu tun.

AMDs Kernel-Entwickler haben sich zu dieser Maßnahme entschlossen, weil der Random Number Generator (RNG) bei einer Reihe von Boards für 15h- und 16h-CPUs keine Zufallsdaten mehr liefert, nachdem das System aus dem Bereitschaftsmodus (Suspend) aufwacht. Das liegt nicht an den CPUs, sondern an Fehlern in den BIOSen, was unter anderem zu einem Problem mit Systemd geführt hat. Linux kann das Fehlverhalten allerdings nicht beim Booten erkennen; AMDs Kernel-Entwickler haben sich daher entschlossen, die Verfügbarkeit von RDRAND() auch bei korrekt arbeitenden Systemen zu verstecken. Dies lässt sich aber über den neuen Parameter rdrand=force unterbinden.

Beim Schreiben von Programmen für die BPF Virtual Machine des Kernels können Entwickler jetzt Schleifen ganz normal verwenden, wie man es aus anderen Programmiersprache kennt. Bislang ließen sie sich allenfalls nutzen, wenn der Compiler die Schleifen per #pragma unroll zuerst aufgelöst hat. Das war nötig, denn der BPF Verifier hat Loops bislang abgewiesen; damit schützte er Linux vor böswilliger Software, die den Prozessor mit Endlosschleifen vereinnahmt und den Kernel so aus dem Tritt bringt.

Diese Gefahr unterbindet die BPF-Prüfschicht jetzt, indem sie den Ablauf von Schleifen komplett simuliert. Dafür müssen die Schleifen allerdings endlich sein und sie dürfen das Programm nicht so stark aufblähen, dass es mehr als die maximal erlaubten Instruktionen ausführen würde. Dies und einige andere für "Bounded Loops" entstandenen Detailverbesserungen erleichtern das Schreiben von BPF-Programmen, die in einigen Bereichen immer populärer werden – etwa zur besonders effizienten Handhabung von Netzwerkpaketen per XDP (eXpress Data Path) oder Tracing- und Performance-Analysen mit BCC oder Bpftrace.

Zu einem Performance-Gewinn beim Zugriff auf den NFS-Server kann die neue Mount-Option nconnect=n führen, über die sich der NFS-Client des Kernels anweisen lässt, mehrere TCP-Verbindungen zum Server aufzubauen (u a. 1, 2, 3, 4, 5).

Ext4 soll dank eines weiteren Cache jetzt oft schneller arbeiten, wenn es die Groß- und Kleinschreibung ("Case Insensitivity") über das bei Linux 5.2 eingeführte "Casefold Feature" ignoriert.

Dank Support für die Intel Speed Select Technology (ISST) können Admins das Stromsparverhalten einiger moderner Xeon-Prozessoren in Zukunft besser an die jeweiligen Gegebenheiten und Bedürfnisse anpassen.

Linux unterstützt die jüngst definierten x86-Instruktionen UMONITOR, UMWAIT und TPAUSE, die Intel bald in Server-Prozessoren unterstützen will (1, 2, 3, 4, 5). Programme können mit ihnen kurzzeitig warten, belasten dabei die CPU aber nicht mit unnützer Arbeit, wie es die bislang in solchen Situationen oft verwendeten Busy Loops tun. Details dazu liefert der LWN.net-Artikel "Short waits with umwait"

Ab Linux 5.3 handhabt der Kernel die Multi-Die Topology einiger High-End-CPUs von Intel besser. Das ist für bestmögliche Geschwindigkeit wichtig, damit der Kernel Prozesse und die von ihnen verwendenden Arbeitsspeicherbereiche möglichst nahe beieinander hält.

Neu dabei ist auch der Support für die x86-Prozessorarchitektur der chinesischen Firma Zhaoxin, die das Design der früher von VIA produzierter x86-Prozessoren wie C3, C7 und Nano weiterentwickelt.

Durch einen Cpufreq-Treiber für den Raspberry Pi kann Linux jetzt die Firmware bitten, den Prozessor des populären Einplatinencomputers mit einer bestimmten Frequenz zu betreiben. Die Firmware, die ohne den Treiber autark entscheidet, kann sich allerdings über den Wunsch hinwegsetzen.

Linux 5.3 bringt Code zum Betrieb unter der Virtualisierungslösung ACRN mit. Dabei handelt es sich um einen Hypervisor, der vor allem für den Echtzeiteinsatz und sicherheitskritische Systeme gedacht ist. Er wird in einem Projekt vorangetrieben, dem die Linux Foundation hilft.

Der Mainline-Kernel unterstützt nun auch das mit i.MX8MQ-Prozessor ausgestattete Board, das Purism mit dem Entwicklerkit für seine Linux-Smartphones Librem5 vertreibt. Das ist aber nur eine von über ein Dutzend mit ARM- oder ARM64-Prozessor ausgestatteten Platinen, die Linux fortan anzusprechen weiß; die anderen nennt ein Git-Merge-Kommentar, der auch darauf hinweist, dass viele Boards die bei Linux 5.2 dazugestoßenen Treiber für Mail-GPUs von ARM jetzt automatisch laden.

Intels Grafiktreiber ist in der Lage, Bildschirme mit HDR (High Dynamic Range) anzusteuern. Bis normale Anwender das ohne Handstand nutzen können, müssen aber auch Userspace-Treiber, Desktop-Umgebungen und Programme lernen, dieses neue Kernel-Feature zu nutzen. Der i915 genannte Grafiktreiber beherrscht das Ganze ohnehin nur bei recht neuen Prozessoren seit den Generationen Ice Lake und Gemini Lake.

Intels Grafiktreiber spricht zukünftig bei Angabe des Kernel-Parameters i915.force_probe=* auch GPUs an, bei denen der Treibersupport bekanntermaßen noch unvollständig ist. Bislang gelang das via i915.alpha_support=1, aber der Parameter soll bald entfallen, weil die Bezeichnung einige Anwender verwirrt habe. Beide Parameter funktionieren ohnehin nur, wenn man sie beim Bau des Kernel-Images freigibt (CONFIG_DRM_I915_ALPHA_SUPPORT respektive CONFIG_DRM_I915_FORCE_PROBE).

Der MSM-Treiber unterstützt jetzt auch die Adreno-A540-GPU. Sie steckt unter anderem im Qualcomm-SoC (System on Chip) MSM8998, der als "Snapdragon 835" in einigen mit Windows ausgelieferten ARM-Notebooks steckt.

Der Grafikkern des Raspberry Pi 4 lässt sich dank "Compute Shader Dispatch" im V3D-Treiber nun auch für allgemeine Berechnungen nutzen.

Über neue Kernel-Parameter kann man die Grafiktreiber des Direct Rendering Managers (DRM) jetzt anweisen, das Bild gleich zu drehen; außerdem lassen sich darüber Overscan-Einstellungen setzen, um das Bild besser einzupassen.

Der Video-Beschleunigungstreiber Cedrus kann nun das Decodieren von H.264 an die Hardware delegieren, die das typischerweise effizienter als der Hauptprozessor erledigt; das reduziert den Stromverbrauch und ermöglicht der CPU, sich um andere Dinge zu kümmern. Dieser maßgeblich über eine Crowdfunding-Kampage vorangetriebene Treiber spricht die Video-Engine einiger Allwinner-Prozessoren an, die sich auf einer Reihe von Einplatinencomputern finden. Kernel-Erweiterungen zum H.265-Support sind noch in Arbeit.

Über einen neuen, per Reverse Engineering entstandenen Treiber unterstützt Linux jetzt die Tastaturen und Trackpads vieler moderner Apple-Notebooks – darunter laut Treiberbeschreibung die MacBooks seit dem Modell 8,1 und MacBook-Pro-Geräte der Reihen 13,* und 14,*. Bei diesen Notebooks sind die Eingabegeräte nicht mehr per USB, sondern per SPI (Serial Peripheral Interface) angebunden.

Der unter anderem für Tastaturbeleuchtung, Lüfterregelung und Funktionstasten von Asus-Geräten zuständige Kernel-Treiber unterstützt jetzt Gaming-Notebooks der TUF-Serie (u. a. 1, 2, 3, 4).

Neu dabei ist auch ein Treiber für die Funktionstasten vieler Xiaomi-Notebooks. Der Joystick-Treiber des Kernels erkennt jetzt auch das Saitek R440 Force Wheel. Der Treiber für Grafiktabletts von Wacom unterstützt jetzt die zweite Generation des Intuos Pro und das MobileStudio Pro.

Eine Änderung bei den Audio-Treibern soll die aus unbekannten Gründen entstehenden Knackgeräusche aus der Welt schaffen, die bislang bei vielen neueren Systemen mit AMD-Prozessoren auftreten.

Linux kann in einem Netzwerk der Fernwartungstechnik IPMI (Intelligent Platform Management Interface) jetzt auch als Satellite Managment Controller (MC) agieren. Das gelingt über einen neuen Slave-Treiber für den Intelligent Platform Management Bus (IPMB), der Anfragen des Baseboard Management Controller (BMC) beantworten kann.

Wie bei jeder neuen Linux-Version haben die Kernel-Entwickler wieder zahlreiche Änderungen vorgenommen, durch die Linux bekannte Hardware-Macken automatisch abfängt und so besser läuft. Beim Packard Bell EasyNote MZ35 etwa funktioniert die Helligkeitsregelung jetzt korrekt und nicht mehr in Schritten, die doppelt so groß sind wie vorgesehen. Das passierte bislang durch einen Fehler in der Firmware des Notebooks: Beim Betätigen der Funktionstaste passte sie die Helligkeit selbst an, auch nachdem Linux der Firmware mitgeteilt hatte, dass sich das Betriebssystem um die Interpretation der Funktionstaste kümmert und die Firmware nichts tun muss.

Das ist nur eine von vielen Änderungen dieser Art – alle hier aufzuzählen würde die Hersteller vielleicht bewegen, besser aufzupassen, zugleich aber den Rahmen sprengen. Weitere Hintergrunde zur Handhabung bekannter Hardware-Marotten ("Quirks") durch Linux finden Sie im Artikel "Kompatibilitätsprobleme beseitigen und Linux besser machen", der im Sommer 2019 auf ct.de erschienen ist.

Im Oktober erwartete Linux-Distributionen wie Ubuntu 19.10 und Fedora 31 werden wahrscheinlich automatisch ordentliche Treiber für die am 7. Juli vorgestellten AMD-Grafikkarten der neuen Radeon-RX-5700-Serie konfigurieren. Das ist vor allem einer in Linux 5.3 eingeflossenen Erweiterung am Treiber Amdgpu zu verdanken, die Support für die Navi10-GPUs nachrüsten, die auf den neuen Grafikkarten sitzen; es sind die ersten Grafikchips, die zu AMDs neuer Architektur "Radeon DNA" (RDNA) gehören, die "GCN" (Graphics Core Next) beerbt.

Linux 5.3 wird AMDs Radeon RX 5700 XT unterstützen.

(Bild: Carsten Spille/c't)

Die Erweiterung zur Navi10-Unterstützung besteht aus über 450 Patches, durch die der Kernel-Quellcode von zirka 26,6 auf satte 27 Millionen Zeilen wuchs. Von den rund 400.000 neuen Codezeilen stecken allerdings ungefähr 348.000 in weitgehend computergenerierten Header-Dateien, die die Hardware-Beschreibung enthalten und somit Register, Standardwerte und Zugriffsmakros definieren (u. a. 1, 2, 3, 4, 5, 6, 7, 8). Solch umfangreiche Header-Dateien waren auch früher schon zum Support neuer AMD-GPUs in den Kernel eingeflossen.

Durch die Erweiterung des Amdgpu-Treibers ermöglicht der Linux-Kernel jetzt die Nutzung aller wesentlichen Funktionen von Navi10-Grafikchips – also die Bildschirmansteuerung über die Display-Engine, die Stromsparfunktionen, die De- und Encoder zur Video-Beschleunigung sowie die Einheiten, die sich um generische Berechnungen (Compute) und 3D-Beschleunigung kümmern. Das Wort "ermöglicht" deutet es schon an: Die kernelseitige Unterstützung ist nur ein Baustein für alle diese Aufgaben, denn allein ist sie zu nicht viel mehr als der Monitorkonfiguration und der Bildausgabe nütze. Um die anderen erwähnten Funktionen in Linux-Programmen verwenden zu können, sind noch eine Handvoll weiterer Userland-Treiber nötig. Die sprechen allerdings nie direkt mit der Hardware, sondern immer über den Kernel-Treiber Amdgpu.

Die 3D-Beschleunigung der Radeon-RX-5700-Karten wird sich beispielsweise mit dem OpenGL-Treiber Radeonsi und dem Vulkan-Treiber Radv nutzen lassen, die das im September erwartete Mesa 19.2 mitbringen wird.

Die entsprechenden Erweiterungen für Radeonsi stammen von AMD-Entwicklern. Die Navi-Unterstützung für den Radeon-Vulkan-Treiber Radv haben hingegen Programmierer von Valve und Google eingebracht, die den Treiber zusammen mit Red-Hat-Leuten und anderen Entwicklern gestartet haben und nach wie vor vorantreiben.

Die OpenGL- und Vulkan-Treiber Radeonsi und Radv brauchen aber nicht nur die Hilfe des Kernel-Treibers Amdgpu, sondern auch die der Compiler-Infrastruktur LLVM. Auch die muss daher Navi-Unterstützung bieten. Die haben AMD-Mitarbeiter jüngst in den Entwicklerzweig von LLVM eingebracht, daher findet sich Navi-Support im dieser Tage erwarteten LLVM 9.0.

Damit nicht genug: Userland-Treiber wie die von Mesa sprechen nicht direkt mit dem Kernel-Treiber Amdgpu, sondern interagieren mit ihm über die Libdrm. Auch die muss daher Navi-Support bieten, was seit Libdrm 2.4.99 bereits der Fall ist.

AMDs Grafiktreiber für den X-Server von X.org, Xf86-Video-Amdgpu, unterstützt die neuen Grafikkarten bereits, denn er braucht für neue GPUs gar nicht angepasst zu werden. Kein Wunder, denn Bildausgabe und Monitorkonfiguration obliegen ohnehin dem Kernel-Treiber – heuer delegieren X-Server-Treiber daher viele Aufgaben dorthin, um die sie sich früher selbst kümmern mussten. Das ist auch der Grund, warum Wayland-Compositoren (etwa Gnome-Shell und KDE Plasma im Wayland-Modus) keinen derartigen Treiber brauchen und schon mit dem auskommen, was Kernel- und Mesa-OpenGL-Treiber bieten.

Der von AMD selbst vorangetriebene und daher mit Radv konkurrierende Vulkan-Treiber AMDVLK (AMD Open Source Driver for Vulkan) unterstützt Navi10-GPUs seit Version 2019.Q3.2, die AMD neun Tage nach Einführung der RX 5700 freigegeben hat. Radv wusste Navi zu dem Zeitpunkt bereits einige Tage anzusprechen.

Letztlich braucht man daher Linux 5.3, Libdrm 2.4.99, LLVM 9.0 und Mesa 19.2, um die 3D-Beschleunigung von RX-5700-Grafikkarten verwenden zu können. Alle diese Versionen erscheinen in den nächsten Wochen und dürften dadurch in viele Linux-Distributionen einfließen, die im Herbst erscheinen.

Mehr Infos

Die Grafiktreiber-Architektur von Linux

Bei Linux ist es ganz normal, dass man einen Schwung von Treibern braucht, um die vielen Funktionen moderner PC-Grafikchips zu nutzen. Der Grafikstack zum Support von Intel-GPUs ähnelt daher jenem für Grafikchips von AMD. Von der Komplexität bekommen die meisten Anwender aber nichts mit, weil sich alle Treiber automatisch konfigurieren. Hintergründe dazu erläutert der kostenlos abrufbare Artikel Die Grafiktreiber-Architektur von Linux aus c't 23/2014.

Wie uns ein Entwickler mitteilte, sollten die in Mesa enthaltenen Treiber auch schon in der Lage sein, Videos mit der Video-Engine von Navi-GPUs zu de- oder encodieren. Das gelingt bei modernen Radeon-Chips über Treiber für die Programmierschnittstellen OpenMAX (OMX), VA-API (Video Acceleration API) und VDPAU (Video Decode and Presentation API for Unix), die aktuellen Mesa-Versionen beiliegen. Durch die Kürze der Zeit konnten wir zur Publikation des Textes nicht klären, wie es um Userspace-Treiber zum Compute-Support steht; also Treiber zur Verwendung von Grafikchips für allgemeine Berechnungen (GPGPU/General Purpose Computation on Graphics Processing Units). Alles, was Kernel-seitig dazu nötig ist, bringt 5.3 indes mit.

Userspace-Treiber wie die von Mesa eignen sich für verschiedene Chips der Navi-Reihe. Der Linux-Kernel hat bislang nur Unterstützung für den Navi10 der RX-5700-Modelle gelernt. Änderungen zum Support der GPUs Navi12 und Navi14 haben den Einzug in Linux 5.3 knapp verpasst, daher sollen sie erst in Linux 5.4 einfließen.

AMD bietet für die Radeon RX-5700-Serie auch Linux-Treiberpakete auf seiner Homepage an, die aber nur für eine handvoll im Unternehmensumfeld gängige Distributionen ausgelegt sind. Mitte Juli bei entstehen dieser Zeilen behauptete die zugehörige Dokument zudem, dass im Archiv zwei Treiberstacks stecken: "AMDGPU All-Open", der nur quelloffene Treiber nutzt, und "AMDGPU-Pro Driver", der auch proprietäre Treiber enthält. Das Installationsskript richtete aber nur den quelloffenen Stack ein; dieses installiert unter anderem einen per DKMS (Dynamic Kernel Module Support) gebauten Amdgpu-Kernel-Treiber und Navi-taugliche Ausführungen von Libdrm, dem Mesa-OpenGL-Treiber Radeonsi, einem X.org-X-Server-Grafiktreiber Amdgpu und Mesa-Treiber zur Video-Beschleunigung über die Programmierschnittstelle OpenMAX, VA-API und VDPAU. Diese Treiber sind sehr eng mit jenen verwandt, mit denen Kernel, Mesa & Co. moderne Radeon-Chips unterstützen.

Mit der Freigabe von Linux 5.3 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.4 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.4 erscheint daher wahrscheinlich am 18. oder 25. November.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne
Doku)²
Entwick-
lungs-
zeitraum
Commits
(Ohne
Merges)³
Diffstat⁴
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(-)
Linux 5.3 65.261 27.141.312
(24.708.822)
70 Tage 15.784
(14.605)
13.983 files changed,
 1.189.832insertions(+),
 600.665 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

In den ersten Stunden nach der Freigabe steht die neue Linux-Version oft nur über einen Git-Checkout des "Mainline" genannten Hauptenwicklerzweigs bereit; die Download-Möglichkeit über die Frontseite von Kernel.org folgt meist erst, 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 startet 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, dritte und vierte Teil einer c't-FAQ-Reihe mit "Basiswissen zum Linux-Kernel".

Mehr Infos

Versionshistorie dieses Artikels

  • 2019-09-16, 07:00 – v2.0: Text anlässlich der Freigabe von Linux 5.3 neu strukturiert, damit die wichtigsten Dinge vorne stehen.
  • 2019-09-04, 06:30 – v1.2: Änderungen bei Infrastruktur und Architektur-Support erläutert.
  • 2019-08-27, 06:30 – v1.1: Neuerungen bei Netzwerk, Storage und Treibern beschrieben; weitere Detailanpassungen am Text zu den RX-5700-Treibern.
  • 2019-07-26, 14:25 – v1.0.1: Detailkorrekturen bei Treiber-Support für Navi10: xf86-video-amdgpu und die Mesa-Treiber für die Video-Engine sollen funktionieren.
  • 2019-07-22, 06:55 – v1.0: Anlässlich der ersten Vorabversion von Linux 5.3-rc1 die Highlights dieser Linux-Version kurz angerissen.
  • 2019-07-17, 06:30 – v0.9: Navi10-/Radeon-RX-5700-Support erläutert.

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

(thl)