Kernel-Log: Grafiktreiber ati aktualisiert, Debatte um Aufnahmezeitpunkt für Linux-Treiber

Eine neue Version des X-Treiberpakets ATI bringt zahlreiche Verbesserungen sowie Unterstützung für die drei neusten Radeon-Grafikkartengenerationen. Die Kernel-Entwickler debattieren derweil, wie ausgereift ein Treiber sein muss, bevor sie ihn aufnehmen.

In Pocket speichern vorlesen Druckansicht 78 Kommentare lesen
Lesezeit: 6 Min.
Von
  • Thorsten Leemhuis

Die Programmierer des seit langem im Rahmen von X.org entwickelten Treiberpakets "ati" haben nach zahlreichen Vorabversionen nun die Version 6.8 der Grafiktreiber für ältere und neue Grafikchips von AMD/ATI veröffentlicht. Sie bringt gleich zahlreiche Neuerungen. Die wichtigste dürfte die Unterstützung der drei neusten Generation von Radeon-Grafikkarten sein (Radeon X1xxx – X3xxx). Für diese in den letzten zwei Jahren vertriebenen Karten musste man bis zum Herbst 2007 zumeist den proprietären Fglrx-Treiber von AMD/ATI nutzen, weil ATI keine Informationen zu den Chips rausrückte und es daher keine Open-Source-Treiber gab.

Parallel zur Veröffentlichung der Grafikchip-Dokumentation von AMD/ATI entstand dann im vergangenen Jahr der maßgeblich von Novell-Entwicklern programmierte Open-Source-Treiber "radeonhd", der sich ausschließlich für die drei neusten Radeon-Grafikkartengenerationen eignet. Der seit einigen Wochen bei AMD angestellte X-Entwickler Alex Deucher sowie der bei Red Hat beschäftige X- und Kernel-Entwickler Dave Airlie integrierten wenig später Unterstützung für die neusten Radeon-Generationen auch in den Entwicklerzweig des Treiber-Pakets "ati", aus dem die nun veröffentlichte Version 6.8 hervorging. Sie eignet sich damit sowohl für ältere ATI-Chips wie mach64 und r128 als auch für die neusten nun unter AMD-Logo vertriebenen Radeon-Chips. Welcher der beiden Open-Source-Treiber langfristig das Rennen macht, lässt sich bislang nicht abschätzen.

Die Kernel-Entwickler diskutieren derweil, wie weit Treiber-Code gereift sein muss, bevor sie einen neuen Treiber aufnehmen. Auslöser war ein erstmals in den Linux-Hauptentwicklerzweig integrierter Treiber, der noch recht jung ist und laut einigen Kernel-Entwicklern einige offensichtliche Probleme aufweist. So kam die Frage auf, ob der Treiber angemessen begutachtet ("reviewed") wurde, bevor er in den Kernel aufgenommen wurde.

Ein Review hatte der zuständige Subsystem-Verwalter laut eigenen Aussagen durchaus durchgeführt und dabei auch einige Verbesserungen gefordert, die der Treiber-Programmierer auch umsetzte. Der Reviewer sah weiteres Verbesserungspotenzial, wollte die Weiterentwicklung allerdings im Rahmen des normalen Kernel-Entwicklerzweigs betreiben und übermittelte den Treiber daher an Torvalds, der ihn in den zu 2.6.25 führenden Hauptentwicklerzweig integrierte.

Ob das verfrüht und das Review ausreichend war, sind nun die Hauptpunkte der Debatte. Einige Entwickler inklusive Torvalds halten das Vorgehen für akzeptabel, denn dann können andere Programmierer Korrekturen für den Treiber einsenden und ihn so zusammen weiterentwickeln. Torvalds spricht sich zudem dafür aus, neue Treiber generell schnell zu integrieren ("[...] I really do believe that we should merge drivers in particular a lot more aggressively").

In der Vergangenheit hatten einige Kernel-Entwickler teilweise recht hohe Ansprüche an die Code-Qualität neuer Kernel-Treiber und an deren Programmierer gestellt. Das war für manche Entwickler eine zu hohe Hürde und sie entwickelten ihre Open-Source-Treiber lieber unabhängig vom Kernel weiter. Beispiele gibt es dafür reichlich: die Lirc-Kernel-Treiber etwa, verschiedene WLAN-Treiber sowie Webcam-Treiber wie gspcav. Leidtragende waren häufig die Anwender: Wenn die Verwalter der Distributionskernel die Treiber nicht integrierten, mussten sie sich selbst um Installation und Pflege der Treiber kümmern – ein zeitaufwendiges und häufig schwieriges Unterfangen, das deshalb auch die Verwalter der Distributionskernel gerne zu meiden versuchen.

Sollten die Kernel-Entwickler im Rahmen der Diskussion die Aufnahmevoraussetzungen weiter senken, dürften so manche der externen Treiber über kurz oder lang den Weg in den offiziellen Linux-Kernel finden. Zusammen mit dem Treiber-Entwicklungsprojekt von Greg Kroah-Hartman dürfte das die Hardware-Unterstützung von Linux weiter verbessern und den Anwender und Distributoren einige Probleme abnehmen. Anfangs mag die Qualität der Treiber vielleicht nicht die Beste sein, erfahrungsgemäß werden die Treiber aber schon kurz nach der Integration in den Kernel meist deutlich besser als extern gewartete Treiber, da andere Linux-Entwickler nun über die ihnen bekannten Wege Korrekturen und Verbesserungen beisteuern.

Kernel-Log-Staccato: Auf das im vorangegangenen Kernel-Log erwähnten Hdparm 8.1 folgte wenig später die Version 8.2, die einige wichtige Korrekturen mitbringt – der Autor empfielt allen Anwendern daher das Update auf die neuste Version.
Die Entwickler des Realtime-Kernelzweigs haben eine neue Version des RT-Trees veröffentlicht, die nun die für die Aufnahme in den offiziellen Kernel-Zweig vorgesehen Ftrace-Infrastruktur zum Latency-Tracking nutzt.
Das experimentellen Btrfs-Dateisystem ist nun in Version 0.13 erhältlich.

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich auch in den vorangegangen Ausgaben des Kernel-Logs auf heise Open: