Linux: Kernel-Entwickler drücken freie Grafiktreiber durch

Inhaltsverzeichnis

Die Vorwürfe sind so alt wie Linux: Die Kernel-Entwickler erschweren die unabhängige Entwicklung von Grafiktreibern für Linux. Damit würden sie der Linux-Welt einen Bärendienst erweisen; sie sollen lieber Lizenz-Barrikaden einreißen und stabile Programmierschnittstellen für Treiber schaffen. Forderungen dieser Art finden sich zehntausendfach im Internet, einige davon aus der Frühzeit von Linux. Ein Blick auf jüngste Entwicklungen zeigt jedoch: Für die Kernel-Entwickler hat es sich ausgezahlt, hart zu bleiben. Gerade weil sie es externen Treibern seit jeher schwer machen, gibt es mittlerweile für alle gängigen Grafikkerne quelloffene Kernel-Treiber; in fast allen Fällen stammen die sogar von den Herstellern selbst und sind Teil von Linux, genau wie es Linus Torvalds und seine Mitstreiter wünschen. Dennoch bleibt die Lage bei Grafiktreibern vertrackt.

Nvidia beugt sich dem Druck

GeForce-GPUs sind das bekannteste Beispiel für Grafikkerne, deren Hersteller lang und erfolgreich voll auf proprietäre Linux-Treiber gesetzt hat. Das änderte sich erst im Mai 2022, als Nvidia überraschend einen Kernel-Treiber unter Open-Source-Lizenz veröffentlicht hat.

Dieser als nachladbares Kernel-Modul übersetzbare Treiber wird aber allem Anschein nach nie in den Linux genannten Betriebssystemkern einfließen, der von jeher Kernel-Basisinfrastruktur und Treibercode verquickt. Linux profitiert dennoch: Red-Hat-Entwickler verbessern mit Code und Informationen aus Nvidias Modul gerade den im Kernel enthaltenen Nouveau-Treiber.

Durch die Umbauten lernt Nouveau mit dem jüngst freigegebenen Linux 6.6 und der Anfang Januar erwarteten Version 6.7, "Ada Lovelace"-GPUs von GeForce-40xx-Grafikkarten anzusprechen. Mittelfristig soll das Ganze auch den bislang eher rudimentären Support für die Vorgänger "Ampere" (u.a. 30xx-Serie) und "Turing" (u.a. 20xx-Serie) signifikant verbessern und die 3D-Performance deutlich steigern; der Code dazu steckt schon im Kernel, liegt standardmäßig aber vorerst brach. Weitere Verbesserungen, die indirekt Nvidias offenem Treiber zu verdanken sind, reifen derweil bereits und sollen in die nächsten Linux-Versionen einfließen.

Nvidias 3D-Treiber bleiben proprietär

Wohlgemerkt hat Nvidia lediglich Code eines Kernel-Moduls offengelegt, der beim Grafiktreiberstack nur das Fundament bildet. Denn die darauf aufsetzenden Treiber bleiben proprietär – etwa jene für 3D (OpenGL und Vulkan), Videowiedergabe (NVDEC), Videoencoding (NVENC) oder allgemeine Berechnungen (CUDA) mittels GPU. Offene Treiber für Nvidias Modul gibt es nicht. Darum nehmen die Linux-Entwickler es auch nicht auf, denn proprietäre Treiber machen eine ordentliche Qualitätskontrolle unmöglich und erschweren die Validierung späterer Änderungen. Ohnehin sperren sich Torvalds & Co. in der Regel gegen die Aufnahme von Treibercode für Hardware für die der Kernel schon einen Treiber mitbringt.

Diese nicht im Kernel-, sondern im Userspace laufenden Treiber arbeiten nicht mit Nouveau zusammen – wer sie einsetzen will, braucht eines der beiden Kernel-Module von Nvidia. Bis auf weiteres zumeist das altbekannte proprietäre Modul, denn dem quelloffenen fehlen noch mehrere Funktionen, die für Desktop- und Notebook-GPUs wichtig sind. Die rüstet Nvidia langsam nach.

Irgendwann kann das Modul so vielleicht die Handhabung von Nvidias Treiberstack erleichtern, der bei der Installation gerne mal zickt und bei Kernel-Updates schnell in Schieflage gerät. Dazu müssen Distributionen das Modul aber vorkompiliert mitliefern. Manche scheuen derlei, weil sie dann erst auf eine neue Kernel-Version wechseln können, wenn Nvidia oder jemand anders das Modul zu dieser kompatibel gemacht hat. Andere Distributionen scheuen diese Abhängigkeit nicht und haben teilweise sogar schon das proprietäre Modul vorkompiliert beigelegt, obwohl Teile der Open-Source-Community darin einen Verstoß gegen die Lizenz von Linux sehen: der GPLv2.

Unabhängig entwickelte Vulkan- und Video-Wiedergabe-Treiber

Dank engagierten Open-Source-Entwicklern brauchen manche Anwender die proprietären GeForce-Treiber aber vielleicht bald nicht mehr. Denn unter Federführung einer Mitarbeiterin von Collabora ist mit "NVK" ein auf Nouveau aufbauender Userspace-3D-Treiber entstanden, der bereits Vulkan 1.0 meistert. Er floss kürzlich in Mesa ein, das auch die offenen 3D-Treiber für AMD- und Intel-GPUs beherbergt, die Debian, Fedora, Ubuntu & Co. standardmäßig einrichten.

Noch im Experimentierstadium steckt derweil ein neuer Userspace-Treiber zur beschleunigten Video-Wiedergabe via Nouveau, an dem ein Red-Hat-Mitarbeiter arbeitet. Für Büroarbeitsplätze mit modernen Desktops von Gnome- und KDE-Projekt reichen diese Treiber vermutlich mittelfristig vollkommen aus. Für High-End-Gaming, Grafik-Workstations oder Berechnungen auf dem Grafikchip bleiben Nvidias proprietäre Userspace-Treiber aber sicher noch lange die bessere Wahl.

Ohne das offene Kernel-Modul des GeForce-Machers wären die beiden neuen Open-Source-Treiber wohl nie entstanden. Ein großes Hindernis waren fehlende Informationen, um das nötige Fundament in Nouveau zu schaffen. Das noch viel größere Problem war jedoch die beschnittene Firmware, die Nvidia viele Jahre für Linux bereitstellte. Sie konnte GPUs der letzten Jahre weder in ihre sparsamsten noch ihre leistungsfähigsten Betriebsmodi schalten – der ebenfalls Nouveau genannte OpenGL-Treiber von Mesa liefert in Folge vielfach nur eine miserable 3D-Performance.

Warum Nvidia einen Kernel-Treiber offengelegt hat

Durch die Fortschritte werden für PCs gedachte Linux-Distributionen die neuesten GeForce-Chip-Generationen bald besser von Haus aus unterstützen. Auch Linux-Livesysteme wie Desinfec't, für die proprietäre Treiber vielfach keine Option darstellen, laufen dadurch besser.

Das war aber offensichtlich nicht der Grund für Nvidias Kehrtwende. Das zeigt das Open-Source-Modul, das derzeit primär für KI-Beschleuniger gedacht ist – und damit ein starkes Indiz liefert, dass der explodierende Markt für KI-Supercomputer und High Performance Computing (HPC) zum Sinneswandel führte. Dort dominiert Nvidia mit Rechenbeschleunigern, die früher eng mit Gaming-GPUs verwandt waren. Für das Unternehmen wurde es im HPC-Markt aber absehbar immer schwerer, Bestandteile, die für bestmögliche Performance nötig wären, mit einem proprietären Linux-Treiber zu realisieren.

Kernel-Entwickler machen ihre Intention deutlich

Teilschuld daran trägt eine Lizenz-Barriere, denn schon seit zwei Jahrzehnten exportieren die Linux-Entwickler gewisse Methoden nur via "EXPORT_SYMBOL_GPL" an Kernel-Module. Die Autoren des dahinter steckenden Codes wollen damit klarstellen: Diese Funktionen dürfen nur Treiber nutzen, die wie Linux selbst unter der GPLv2 oder einer dazu kompatiblen Lizenz stehen. Checks beim Laden von Modulen versuchen das durchzusetzen, haben aber Schwächen.

Nvidias proprietäres Kernel-Modul hat so gekennzeichnete Methoden meiden können, ohne dass es Funktionsumfang und Geschwindigkeit spürbar limitierte – Indizien zufolge hat der nicht einsehbare Code dabei aber wohl manchmal unsaubere Tricks genutzt, die die Systemstabilität gefährden.

Datenfluss-Optimierung scheitert an Barriere

Der Spielraum wurde mit den Jahren aber immer kleiner, weil die Zahl der GPLv2-Exporte zunahm. Ferner stopften die Linux-Macher einige Schlupflöcher des Lizenz-Lade-Checks. So etwa vor drei Jahren, nachdem Facebook-Entwickler einen Satz von Kernel-Änderungen einreichten. Diese sollten Netzwerk-Treibern des Kernels ermöglichen, die eingehenden Daten mithilfe von Nvidias proprietärem Treiber direkt in den Speicher der GPU zu transferieren. Das steigerte die Performance beim Machine Learning mit Nvidias Beschleunigern, wo riesige Datenmengen fließen.

Vorkommnisse wie diese zeigen Nvidias zweite Motivation für den Sinneswandel: Damit Beschleuniger-Chips bestmögliche Performance liefern, müssen sie immer enger mit dem Rest des Systems zusammenarbeiten. Diesen Aspekt verstärkt sich derzeit abermals durch die zunehmende Verbreitung von Compute Express Link (CXL), eine noch junge Hardware-Verbindungstechnik, die den Aufbau von Systemen in großen Rechenzentren revolutioniert.

Eine möglichst enge Zusammenarbeit gelingt mit einem externen proprietären Treiber schlicht nicht. Die Lizenz-Barrikade ist da ein Problem – aber nicht das einzige, denn auch dem in Linux enthaltenem Treibercode sind Grenzen gesetzt, um Risiken zu reduzieren, die die Systemstabilität gefährden.

Nvidia kann Linux jetzt besser für die eigenen Belange anpassen

Unter einer Bedingung sind die Linux-Entwickler allerdings offen für Anpassungen an der Basisinfrastruktur des Kernels: Wenn sie die Performance des in Linux enthaltenen Treibercodes steigern. Solche Änderungen kann Nvidia jetzt einbringen -- etwa um das Memory Management für seine KI-Beschleuniger zu optimieren oder dort neue Einhakpunkte für Nouveau zu schaffen, damit der Treiber die Daten schneller erhält oder Ergebnisse zurückliefern kann. Diese Verbesserungen könnte Nvidia dann auch in seinem externen Open-Source-Modul nutzen, damit die hauseigenen Produkte besser am Markt dastehen. Genau solche Aspekte sind ein Grund, warum sich hunderte andere Unternehmen schon lange an der Linux-Entwicklung beteiligen – und den Kernel so nicht nur besser machen, sondern auch mit einem Strom an Entwicklern versorgen.

Nvidia hat wohl erkannt, dass ein proprietärer Treiber mittel- bis langfristig zu Wettbewerbsnachteilen geführt hätte, schließlich hat die Firma die Offenlegung eines Kernel-Moduls von langer Hand vorbereitet. Denn schon vor Jahren hat die Firma begonnen, einen GSP (GPU System Processor) genannten RISC-V-Kern in ihre GPUs zu integrieren. Der führt eine proprietäre Firmware aus, die das Kernel-Modul bei der Initialisierung an die GPU schickt – und allerlei Aufgaben erledigt, die zuvor Betriebssystemtreiber erledigen mussten. Dadurch kann Nvidias quelloffenes Modul schlanker ausfallen und es braucht keine Interna enthalten, die die Firma vor neugierigen Augen verbergen will; auch für DRM-Techniken kann das nötig sein, beispielsweise wenn Hersteller ein Abgreifen hochauflösender Videos unterbinden wollen.

Linux: Kernel-Treiber gibt es streng genommen nicht​

Linux ist ein eher monolithischer Kernel. Vereinfacht gesagt ist es damit eine große ausführbare Datei, die alle von ihm unterstützten Funktionen enthält. Code zur Ansteuerung von Grafikkerne ist daher ebenso Kernel wie alles andere und keinerlei Beschränkungen unterworfen. Das unterscheidet Linux von Microkerneln oder dem Hybridkernel von Windows: Dort kann man sich den Kernel eher wie das Grundgerüst mit Abstraktionsschicht vorgestellten, an dem bis zu einem gewissen Grad abgeschottet arbeitende Treiber andocken.

Weil die "ausführbare Datei" immer größer wurde, haben die Entwickler bei Version 2.0 die Möglichkeit nachgerüstet, Teile in Module auszulagern. Dazu haben sie Kommunikationswege geschaffen, die die Linux-Entwickler als Kernel-interne Schnittstellen ansehen. Diese passen sie immer mal wieder an, wodurch extern gewartet Treiber wie die von Nvidia gelegentlich auf die Nase fallen, denn die klinken sich über das Modul-Interface ein.

Nvidias Ansatz ist nichts Ungewöhnliches, denn Ähnliches findet sich auch bei dem Grafiktreibercode, den AMD und Intel schon lange im Rahmen des Linux-Kernels entwickeln. Allerdings ist die GSP Firmware von Nvidia deutlich größer und offensichtlich für mehr Aufgaben zuständig.

Übrigens: Nvidias Engagement für quelloffenen, im Rahmen des Kernels entwickelten Treibercode ist nur neu, wenn es um Grafik- und Beschleunigerchips für PCs und Server geht. Denn die Firma arbeitet schon lange am Kernel mit, damit Linux seine hauseigenen Tegra-Prozessoren möglichst gut unterstützt. 2014 hat sie sogar erstmals direkt zum Nouveau-Code des Kernels beigetragen, damit er zumindest die Grundfunktionen der GPUs unterstützt, die in diesen Embedded-Prozessoren mit ARM-Kern stecken.

Kehrtwende in der Embedded-Welt

Neben Nvidia engagieren sich neuerdings zwei weitere Branchgrößen für quelloffene Linux-Grafiktreiber. Eine davon ist für die Computer-Welt ähnlich bedeutsam: ARM.

Das Unternehmen hatte ein ambivalentes Verhältnis zu quelloffenen Treibern, denn auch ARM arbeitet schon lange intensiv am Linux-Kernel mit. Damit macht sie ihre CPU-Designs am Markt attraktiver, schließlich verkauft sie die meist an Firmen, die damit für den Linux-Einsatz gedachte Prozessoren bauen. Bei seinen GPU-Designs der Mali-Serie gab sich ARM aber von jeher zugeknöpft und setzte auf proprietäre Treiber, die sich über ein eigenes quelloffenes Kernel-Modul bei Linux einklinken. Prozessoren mit solchen GPUs finden sich in allen möglichen Produkten, besonders häufig in Smartphones, Tablets, Chromebooks und Einplatinencomputern.

Vor drei Jahren leitete ARM dezent eine Kehrtwende ein: Über Aufträge an die Firma Collabora begann das Unternehmen, die Entwicklung quelloffener Kernel- und OpenGL-Treiber für die neuesten Mali-Designs zu fördern. Diese in Linux und Mesa enthalten Treiber waren zuvor unabhängig von ARM unter dem Namen "Panfrost" entstanden, wobei Collabora dort schon stark angeschoben hat. Im Juli 2023 hat sich ARM dann voll hinter die Treiber gestellt und eine Kooperation mit Collabora verkündet. Panfrost soll fortan der "Treiber für die Linux-Community" sein. Damit Kernel- und OpenGL-Treiber die Mali-GPUs zukünftig erstklassig unterstützen, wollen die beiden Firmen die Performance verbessern und für Support zukünftiger Mali-Generationen sorgen.

Ähnlich wie Nvidia pflegt ARM sein Kernel-Modul und seine proprietären Userspace-Treiber weiter. ARM ist allerdings nicht ganz so gut darin, den Code zum Bau des eigenen Kernel-Modules zeitnah kompatibel zu neuen Linux-Versionen zu machen. Das ist meist alle paar Monate nötig, weil die Kernel-Entwickler immer mal wieder Methoden verändern, über die verschiedene Teile von Linux (und damit auch sein Treibercode) miteinander interagieren. Dadurch ändern sich auch die an Module exportierten Symbole, um Kernel-Methoden zu nutzen.

Sich ständig veränderte Kommunikationswege

Diese Umbauten nehmen sie vor, um die Performance zu optimieren oder den Code zu vereinfachen; zumeist schaffen sie aber Infrastruktur zur Unterstützung neuer Einsatzgebiete, Geräteklassen oder Hardware-Features. Durch die Verquickung von Kernel-Basisinfrastruktur und Treibercode brauchen Torvalds & Co. dabei keinerlei Rücksicht auf Abwärtskompatibilität nehmen: Entwickler, die eine Methode verändern wollen, welche an Module exportiert wird, müssen zugleich alle Stellen im Kernelcode anpassen, die diese Methode nutzen – auch dann, wenn sich niemand mehr aktiv um die betroffenen Codestellen kümmert. Letzteres ist bei Treibercode keine Seltenheit, denn der fliegt normalerweise erst raus, wenn ihn allem Anschein nach niemand mehr produktiv mit Linux nutzt. Genau deshalb unterstützen aktuelle Kernel viel Hardware, die zuletzt vor weit über einem Jahrzehnt über die Ladentische ging und nicht mit aktuellen Windows-Versionen spielt.

Linux kann sich so Kompatibilitätscode zur Unterstützung alter Treiber sparen und das Ruder herumreißen, wenn technische Umwälzungen oder krasse Fehlentscheidungen beim Codedesign dies erfordern. Das war etwa beim USB-Stack mehrfach nötig. Auch der Schutz vor Prozessor-Sicherheitslücken wie Spectre konnten die Kernel-Entwickler effizienter realisieren als Windows, eben weil sie den Code aller gängigen Treiber zur Hand hatten, um den gleich mit anzupassen.

Der Verzicht auf stabile Modulschnittstellen verkompliziert aber die externe Entwicklung und Pflege von Kernel-Treibern: Ihre Programmierer müssen den Code flexibel auslegen und immer mal wieder aktualisieren, damit er zu den Modul-Exporten von älteren Linux-Versionen ebenso passt wie zu brandneuen.

Motivation zur Mitarbeit am Kernel

Der Grund, dass die Linux-Entwickler darauf noch nie Rücksicht genommen haben: Das Fehlen stabiler Schnittstellen hat indirekt zum Erfolg des Kernels beigetragen. Und das sogar erheblich. Denn durch diesen Aspekt haben schon tausende Firmen erst ihre Treiber in Linux integriert, aber später dann auch andere Verbesserungen zum Kernel beigesteuert.

Davon profitieren Anwender, weil die Linux-Entwickler die Beitragenden nötigen, bei der Basisinfrastruktur für alle Treiber einer Geräteklasse zusammenzuarbeiten. Dadurch trägt dann vielleicht Nvidia eine Optimierung am Fundament für Grafiktreiber bei, durch die auch GPUs von AMD schneller laufen – und umgekehrt.

Die Linux-Entwickler unterbinden durch ihre Spielregeln zudem Hersteller-spezifische Schnittstellen rund zur Nutzung und Konfiguration von Hardware. Bei Linux-Distributionen beziehungsweise -Desktops kann man so mit einem Bildschirmkonfigurations-Werkzeug die Grafikchips verschiedenster Hersteller auf die immer gleiche Weise einstellen; das macht Hersteller-spezifische Tools unnötig, die einen womöglich ausspionieren oder gar die Systemsicherheit gefährden.

Und noch ein eher versteckter Vorteil von im Kernel enthaltenen Treibern will erwähnt werden: Hersteller haben keine Kontrolle über den Code. Sie können Kunden durch Einstellen der Pflege eines Treibers nicht nötigen, Geld in neue Produkte zu stecken. Gewiefte Entwickler rüsten zudem Features nach, die der Hersteller vielleicht lieber späteren Produktgeneration vorbehalten hätten. Oder sie machen den Treiber und damit die Hardware für Einsatzgebiete fit, die den Hersteller nicht jucken – etwa Support für Prozessor-Architekturen jenseits von ARM und x86.

Problemkind hat ein Einsehen

Neben ARM versorgt eine weitere Partei im Embedded-Markt seine Grafikkern-Designs neuerdings mit quelloffenen Treibern: Imagination Technologies. Die PowerVR-Kerne sind im Markt seltener anzutreffen als ARMs hauseignes Grafikkerndesign, finden sich aber in allerlei Mobilgeräten und Einplatinencomputern.

Imagination hat in der Open-Source-Szene einen miserablen Ruf. Das liegt an den proprietären Treibern, die die Firma viele Jahre bereitgestellt hat. Anders als jene von ARM oder Nvidia eigneten die sich oft nur für veraltete Linux-Versionen oder nur für den auf dem Gerät vorinstallierten Kernel. In Folge dessen kann man bei vielen Produkten mit PowerVR-Grafik nur schwerlich oder gar nicht auf neue Linux- oder Betriebssystemversionen wechseln.

Ähnliche Probleme gab es vor fünfzehn Jahren auch in der PC-Welt mit den ersten Generationen von Intels Atom-Prozessoren, denn auch in denen steckten PowerVR-Kerne von Imagination. Solche CPUs fanden sich häufiger in Netbooks oder Tablets mit Linux-basierten Betriebssystemen. Allerwelts-Distributionen liefen auf diesen Geräten aber vielfach mehr schlecht als recht: Imaginations Treiber arbeiteten oft nicht oder nur unter Einschränkungen mit den Kerneln von Fedora, Ubuntu & Co. zusammen, selbst wenn die nur ein bisschen neuer waren. Diese Situation verschlimmerte sich innerhalb weniger Monate und bereitete Anwendern damals sehr viel Kopfzerbrechen.

Im Frühjahr 2022 hat das Unternehmen angekündigt, in Zukunft auf Open-Source-Treiber zu setzen. Das ging mit einem Vulkan-Treiber los, der in Mesa eingeflossen ist. Später folgte einen Kernel-Grafiktreiber für die neueste Generation der PowerVR-Grafikkerne, den die Linux-Entwickler kürzlich zur Aufnahme in Kernel 6.8 akzeptiert haben.

Andere hatten früher ein Einsehen

Damit gibt es dann quelloffene Kernel-Treiber von allen großen Unternehmen, die Grafikkerndesign für Prozessoren anbieten, die in für Linux gedachten Embedded-Systemen stecken.

Broadcom hat beispielsweise selbst Treiber zu Linux beigesteuert, die VideoCore-Grafikkerne ansprechen, die unter anderem in den Prozessoren der Raspberry-Pi-Serie stecken. Für Qualcomms Adreno-GPUs der in zahllosen Android-Geräten und Chromebooks verbauten Snapdragon-Prozessoren bringt der Kernel ebenfalls einen Treiber mit; er war in der Community entstanden, aber mittlerweile trägt Qualcomm immens zum Treiber bei. Beide Unternehmen arbeiten darüber hinaus an quelloffenen Mesa-Treibern für OpenGL mit.

Auch VeriSilicon, das Unternehmen hinter den Vivante-Grafikkernen, entwickelt schon lange quelloffene Kernel-Treiber – allerdings extern. Diese Treiber dienten Open-Source-Entwicklern als Quelle für einen alternativen Treiber, den Linux mittlerweile seit vielen Jahren mitbringt. Bei OpenGL setzt VeriSilicon auf proprietäre Treiber, aber auch hier haben Programmierer eine Alternative geschaffen.

Nur eine Größe der GPU-Branche stellt keine quelloffenen Linux-Treiber: Apple. Aber warum sollte die Firma das auch, denn im Unterschied zu allen anderen erwähnten sieht Apple seine Prozessoren nicht für den Linux-Einsatz vor. Die Open-Source-Community füllt diese Lücke. So arbeitet das Asahi-Projekt an Kernel- und Userspace-Treibern für die GPUs, die in den ARM-basierten CPUs von MacBook, Mac Mini & Co. stecken.

Rosige Zeiten voraus

Das klingt aus Open-Source- und Linux-Sicht recht rosig. In der Praxis lässt dennoch vieles zu Wünschen übrig: Die Dinge sind im Einzelfall häufig komplizierter, als es dieser Text beschreiben kann, ohne enorm auszuufern. So unterstützen die in Linux enthaltenen Treiber manchmal einige Grafikkerne gar nicht oder beherrschen nur einen Teil der Hardware-Features; das kommt insbesondere bei älteren oder besonders neuen GPUs vor.

Support dafür findet sich dann oft in Treibern direkt vom Hersteller. Egal, ob diese nun quelloffen oder proprietär sind: Viele von ihnen eignen sich nur für ausgewählte, häufig veraltete Kernel-Versionen. Und selbst wenn sich ein Unternehmen engagiert und die Treiber halbwegs zeitnah zu neuen Linux-Versionen kompatibel macht: Während die Linux-Entwickler ihren Treibercode oft ein Jahrzehnt oder länger pflegen, ist bei den Herstellertreibern oft nach wenigen Jahren Schluss.

Upgrade-Probleme durch extern gewartete Treiber

Externe Treiber können Wechsel von Betriebssystem- und Kernel verkomplizieren oder komplett blockieren. Die erwähnten Probleme mit den proprietären Treibern von Imagination zeigen das – sind letztlich aber nur ein Beispiel, denn ähnliche Schwierigkeiten gab und gibt es auch bei extern gewarteten Kernel-Modulen anderer Unternehmen.

Eben solche Einschränkungen sind ein Hauptgrund für die Update-Misere bei Android – und warum selbst Entwickler von LineageOS und anderen von Android abgeleiteten Betriebssystemen manchmal den Support für Geräte aufgeben müssen. Die Problematik hat sogar schon den Machern des ersten Fairphones und anderen Firmen ein Bein gestellt, die ihr Smartphones eigentlich mehrere Jahre mit neuen Android-Versionen versorgen wollten.Allerdings stellt auch Android nur die Spitze des Eisbergs dar, denn ähnliche Schwierigkeiten gibt es auch bei vielen anderen Produkten, die Embedded-Prozessoren oder damit gebaute Boards einsetzen; also bei IoT-Geräten, Robotern, Waschmaschinen, Fernsehern, Autos und vielen weiteren Geräteklassen.

Den Grafikkern-Designern, Prozessor-Herstellern und Firmen, die solche CPUs einsetzen, war das lange egal: Im Embedded-Markt war es lange Usus, Hardware mit einem maßgeschneiderten Betriebssystem auszuliefern. Dessen Software war oft schon bei der Produktvorstellung veraltet und blieb fast immer auf dem gleichen Stand; Sicherheitskorrekturen gab es oft gar nicht oder nur für kurze Zeit. Mit den Jahren haben immer mehr Kunden diese missliche Lage erkannt und Druck auf Firmen ausgeübt, sich für quelloffene und im Rahmen von Linux gewartete Treiber zu engagieren. Wohlgemerkt sind hier weniger die Endkunden gemeint, sondern vor allem die Firmen, die Prozessoren mit den Grafikdesigns verbauen: Autohersteller und deren Zulieferer, Industrie-IT-Anbieter und zahllose andere Unternehmen aus den verschiedensten Branchen.

Mehr und mehr Firmen haben ein Einsehen

Doch auch bei Android-Geräten werden diese Aspekte wichtiger. Daher engagiert sich Google mehr und mehr dafür, auch dort weniger von proprietären Linux-Treibern abzuhängen, die Kernel-Sicherheitskorrekturen und -Versionswechsel erschweren oder gar unmöglich machen.

Außer Google haben auch allerlei andere Firmen die Probleme externer und womöglich gar proprietärer Treiber erkannt. Auch sie haben daher begonnen, beim Produktdesign darauf zu achten, ob passende Treiber für die angedachten Komponenten in Linux stecken. Das ist nicht nur Einsicht zu verdanken, sondern auch neuen Richtlinien der Gesetzgeber. Allen voran die im Herbst 2022 beschlossene EU-Ökodesign-Verordnung für Smartphones und Tablets oder dem jüngst gefundenen Kompromiss zum EU Cyber Resilience Act: Beide verpflichten Hersteller, ihre Geräte für mehrere Jahre mit Security-Updates zu versorgen.

In Linux enthaltener Treibercode macht Firmen das leicht. Sie können ihre Pflicht so zudem autark erfüllen. Sprich: Sie müssen im Fall der Fälle keinen sonst wo sitzenden Grafikkern-Designer um angepasste Kernel-Module anbetteln, der sich das womöglich teuer bezahlen lässt, irgendwann aufgibt oder gar pleitegeht. Mit Treibercode im Kernel können die Produktanbieter zudem heute noch unbekannte oder weit entfernte Probleme lösen – wie das heranrückende Jahr-2038-Problem von 32-Bit-Prozessoren, das Linux-Systeme einiger heute verkaufter Autos durcheinander zu bringen droht.

Summa sumarum

Genau diese Flexibilität ist einer der unscheinbaren Vorteile, die der Verquickung von Kernel-Basisinfrastruktur mit unzähligen Treibern bei gleichzeitigem Verzicht auf stabile Treiberschnittstellen zu verdanken ist. Denn durch eben diesen Spielraum konnte Linux immer wieder neue und unvorhergesehene Einsatzgebiete und Märkte erobern. Es hat zudem immer wieder überraschende Performance-Optimierungen ermöglicht. Vor allem aber befreit sie Nutzer aus der Abhängigkeit von den Herstellern. Anwender können ihre Hardware dadurch oft viel länger nutzen als etwa unter Windows – und müssen kein Geld in neue Geräte stecken, weil der Hersteller bei Qualität und Ausdauer seiner Treiber geizt. Mit stabilen Treiberschnittstellen hätte Linux viel von dem verloren, wofür Anwender den Kernel schätzen.

(ktn)