© Nanduu, photocase.com

Geht es nach dem Willen einzelner Entwickler, haben Binärtreiber im Linux-Kernel bald ausgespielt. Das ist jedoch ein fundamentalistischer Ansatz, der der weiteren Linux-Verbreitung im Weg steht.

Wenn Kernelentwickler darüber streiten, ob sie Binärtreiber lieber zulassen oder verhindern wollen, beschwören sie gerne Endzeitszenarien herauf. Bestes Beispiel ist Arjan van de Ven, der seinen Artikel zum Thema sogar selbst so nennt: “Linux in a binary world… a doomsday scenario” [1]. Folgt man seinen Argumenten, löst schon ein einziger Binärtreiber eine Lawine aus, die nicht mehr zu stoppen ist. Am Ende steht dann eine Linux-Welt, in der es keine quelloffenen Treiber mehr gibt und wichtige Binärtreiber nur noch für bestimmte (kommerzielle) Distributionen zur Verfügung stehen.

Gutes Beispiel: Nvidia

Nun verwenden die meisten Besitzer von Nvidia-Grafikkarten aber schon seit Jahren Binärtreiber, die aufgrund ihres 3D-Supports die allseits beliebten Desktop-Effekte ermöglichen. Das Doomsday-Szenario blieb trotzdem bisher aus. Auch das Bestehen entsprechender Third-Party-Repositories für jede größere Distribution zeigt, dass eine große Nachfrage nach solchen Treibern besteht.

Kein vernünftiger Mensch wird bestreiten, dass es besser wäre, wenn der Treibercode im Quellcode zu Verfügung stünde. Nur ist das eben nicht der Fall und an dieser Situation wird sich auch nichts ändern, ganz egal welche Politik die Kernelentwickler verfolgen – zumindest solange der Linux-Marktanteil gegenüber der Windows-Verbreitung marginal ist. Schaffen die Entwickler es tatsächlich, Binärtreiber technisch vom Kernel auszuschließen, gibt es eben keine leistungsfähigen Nvidia-Treiber mehr. Die Wünsche der User scheinen in den Plänen mancher Kernelentwickler keine große Rolle zu spielen.

Kein Quellcode für Handys

Ein anderes Beispiel sind Mobiltelefone, auf denen in Zukunft mehr und mehr Linux laufen soll, so jedenfalls aktuelle Trendvorhersagen. Doch schon bei Trolltechs Greenphone war nicht der gesamte Quellcode des Systems verfügbar, beispielsweise fehlte der GSM-Treiber. Das ist zum Teil den Regulierungsbehörden geschuldet, weil die Funk-Hardware oft leistungsfähiger ist als erlaubt. Deshalb muss der Treiber zum Beispiel das verfügbare Frequenzspektrum oder andere Leistungsmerkmale begrenzen.

Gleichermaßen wollen Handy-Provider verhindern, dass jemand mit modifizierten Treibern ihr Funknetz missbraucht. In jedem Fall ist kaum davon auszugehen, dass jeder Hersteller den kompletten Code offenlegen wird. Hier gilt also die Devise “Friss oder stirb”. Entweder die Kernelentwickler lassen Binärtreiber zu oder die Zukunft von Linux als Handy-Plattform wird zu Ende sein, bevor sie richtig begonnen hat.

Technik oder Politik?

Technisch spricht meines Erachtens wenig gegen Binärtreiber. Ob die Nvidia-Treiber im Allgemeinen den Linux-Kernel destabilisieren oder nicht – wie es viele Kernelentwickler befürchten -, sei einmal dahingestellt. Jedenfalls war es schon in der Vergangenheit kein Problem für den Ruf einzelner Distributionen, deren Hersteller sich in diesem Fall stets darauf berief, Binärtreiber nicht zu supporten. Kurz gesagt: Wer Binärtreiber verwendet, tut das auf eigene Gefahr. Das ist der Status quo und es gibt keinen guten Grund, daran etwas zu ändern. Zur besseren Qualitätssicherung wäre auch eine Code Review durch unabhängige Entwickler denkbar, die per NDA Stillschweigen über den Quellcode zusichern.

Selbst wenn ein Treiberprogrammierer den Quellcode offenlegt, würde er vielleicht gerne Binärmodule davon bereitstellen, um den Anwendern das Leben leichter zu machen. Denn nicht jeder Anwender hat Lust oder die nötigen Kenntnisse, um Kernelmodule zu kompilieren. Nur sind versionsübergreifende Binärmodule wiederum unmöglich: Zwei Kernel, die sich auch nur in der allerletzten Kommastelle der Versionsnummer unterscheiden, vertragen nicht denselben Treiber. Um wie viel einfacher wäre da das Leben mit einem stabilen Kernel-ABI (Application Binary Interface), das sicherstellt, dass sich ein Treiber für Kernel 2.6.x auf allen Distributionen mit 2.6.x-y laden lässt.

Quellcode inkompatibel

Sogar wer seinen Treiber im Quellcode anbietet, bekommt oft genug Probleme. So ändert sich manchmal schon zwischen zwei Minor-Versionen des Kernels das Quellcode-API derart, dass Treiberentwickler große Teile ihres Code umschreiben müssen. Wer als Hardware-Entwickler Linux-Treiber anbieten möchte, muss also mindestens einen Vollzeitentwickler einstellen, der sich um die Pflege des Kernels kümmert. Ganz zu schweigen von einer Testumgebung mit einer Vielzahl von Distributionen und unterschiedlichen Versionen.

Sicherlich wird niemand kompletten Stillstand bei der Kernelentwicklung fordern. Auf die Freiheit der Entwickler, jederzeit nach Belieben ganze Subsysteme umzuschreiben, beruft sich auch Greg Kroah-Hartman in seinem Plädoyer gegen Binärtreiber ([2], [3]). Dass sich dabei auch von einer Version zur nächsten komplette APIs ändern müssen, mag mir nicht so recht einleuchten.

Mehr Stabilität

Die beste Lösung wären ein stabiles API und ein ABI zumindest über viele Minor-Versionen hinweg. Damit könnten Anwender Third-Party-Treiber mehrere Kernelversionen lang verwenden. Die juristische Frage der GPL ist davon unberührt. Nicht-GPL- und damit Nicht-Source-Treiber können juristisch ausgeschlossen bleiben, wenn es in der Community dafür einen Konsens gibt – oder Linus Torvalds allein darüber entscheidet. De facto werden viele Anwender dann Linux beziehungsweise die Treiber illegal verwenden. Aber das ist jetzt bei den Nvidia-Treibern auch schon der Fall.