Seite 7: Treiber für VMs, Fernwartung, Industrieeinsatz, …

Inhaltsverzeichnis

Treiber für Virtualisierung und Fernwartung

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.

Erweiterten Farbraum pro Bildschirm festlegen

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.

Schrumpfkur und Feintuning beim AMD-Support

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.

Treiber für den Industrieeinsatz

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.

Noch mehr neue und verbesserte Treiber

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.

Stromsparverhalten inviduell festlegen

Ü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.

Optimierungen und Verbesserungen beim Architektur-Support

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