Seite 4: USB-Treiber ausgesperrt

Inhaltsverzeichnis

Ausgesperrt

Informationsquelle Quellcodeverwaltung Viele der Links im Artikel und die an dessen Ende gelisteten Kurzbeschreibung zu weniger wichtigen Änderungen verweisen auf den oder die für die Neuerung jeweils relevanten Commit im Web-Frontend des von Linus Torvalds mit Git verwalteten Linux-Quellcodes. Dort finden sich viele weitere Informationen zu den einzelnen Änderungen und ihren Hintergründen. Auch die im Rahmen des jeweiligen Commit angewendeten Patches sind im Web-Frontend über den Link Commitdiff abrufbar und durch Kommentare und Dokumentationsänderungen häufig auch für Interessierte ohne Programmierkenntnisse eine gute Quelle für weitere Informationen. Das Web-Frontend von Git zeigt im unteren Bereich auch eine Liste der im Rahmen des jeweiligen Commit veränderten Dateien an. Hinter den Dateinamen finden sich Links, über die sich die Änderungen an den einzelnen Dateien separat anzeigen lassen; so kann man sich etwa Änderungen an der Dokumentation oder den für die Kernel-Konfiguration zuständigen Kconfig-Dateien einzeln betrachten.

Wer proprietäre und als Kernel-Modul ausgeführte USB-Treiber nutzt, sollte den Umstieg auf 2.6.25 und spätere Kernel-Versionen noch herauszögern, da sich solche Treiber mit einem unmodifizierten Linux 2.6.25 nicht mehr kompilieren lassen. Ursache dafür ist eine von Greg Kroah-Hartman eingebrachte Änderung, durch die der Kernel einige für USB-Kernel-Treiber zwingend benötigte Schnittstellen nun via EXPORT_SYMBOL_GPL exportiert. Damit möchte der langjährige Kernel-Entwickler und Verwalter des USB-Subsystems klarstellen, dass nur unter der GPL2 oder kompatiblen Lizenzen stehende Treiber dieses API und den dahinter stehenden Code direkt nutzen dürfen – er stammt zu nicht unerheblichen Teilen von Kroah-Hartman selbst.

Diese Änderung war bereits vor zwei Jahren für einige Wochen in der Hauptentwicklungslinie des Kernels enthalten, wurde dann aber kurz vor der Veröffentlichung von 2.6.16 wieder entfernt. Das sollte Firmen wie AVM genug Zeit geben, ihre Linux-Treiber so anzupassen, dass sie wie ein normales Closed- oder Open-Source-Programm im Userspace arbeiten und von da über für Userspace-Anwendungen freigegebene Schnittstellen auf USB-Geräte zugreifen. Diese Möglichkeit hat AVM aber nicht aufgegriffen; die Firma begründete das mit hohen Entwicklungskosten und technischen Schwierigkeiten. Einige andere Firmen haben sogar in den vergangenen zwei Jahren noch neue proprietäre USB-Kernel-Treiber entwickelt, obwohl der Kernel seit Version 2.6.16 bereits mit Warnmeldungen deutlich auf die jetzt umgesetzte Änderung hinwies.

Rein und schnell wieder raus

Die Änderung am USB-System und ein unabhängig davon eingebrachter Patch am Module-Loader sorgten zwischenzeitlich dafür, dass auch der Ndiswrapper keinen Zugriff auf das USB-Subsystem mehr hatte. Nach einigen längeren Debatten auf der Linux-Kernel Mailing List (LKML) wurde der zweite Patch jedoch wieder weitgehend zurückgezogen, sodass der Ndiswrapper seit der vierten Vorabversion von 2.6.25 wieder problemlos mit dem Kernel zusammenarbeitet.

In den Vorabversionen von 2.6.25 war auch der seit Jahren umstrittene, aber in vielen Distributions-Kerneln enthaltene Patch kurzzeitig enthalten, durch den der Kernel auf eine händisch angepasste DSDT (Differentiated System Description Table) aus der Initial-Ramdisk (Initrd) zurück greifen kann, statt die vom Hersteller programmierte DSDT des ACPI-BIOS zu nutzen. Ob man den Anwendern diese Möglichkeit an die Hand geben sollte war allerdings nicht wie sonst die Ursache für Debatten; vielmehr hatte ein langjähriger Kernel-Entwickler die technische Implementierung bereits kurz nach der Integration des Patches nachhaltig kritisiert, da die Initialisierung des Kernels in einer anderen Reihenfolge erfolgt, sofern die Initrd eine modifizierte DSDT enthält.

Daraus entstand eine Debatte, die jedoch ohne Konsens und Folgen verebbte. Einige Wochen später im Entwicklungszyklus von 2.6.25 entfernte Torvalds den Patch dann plötzlich; der Code sei schlicht nicht ausgereift und würde "hässliche Dinge" tun. Einer überarbeiteten und sauber arbeitenden Variante des Patches scheint er jedoch nicht abgeneigt zu sein. Bis es eine solche gibt und sie den Sprung in den Kernel schafft, müssen die Distributoren den von den Kernel-Entwicklern wegen Qualitätsmängeln abgelehnten Patch wohl weiter selbst pflegen.