Schon erstaunlich. Hier ist ein Entwickler eines Kerneltreibers für Phillips Webcams. Dieses Kernelmodul funktioniert, aber um vollständig die Kameras zu unterstützen, braucht es ein binary-only Modul. Die Kernel-Entwickler aber haben entschieden mit den binary-only Modulen aufzuräumen. Auch das Phillips Webcam Modul ist davon betroffen. Als Ergebnis hat der USB Subsystem Maintainer einen Hook aus dem Kernel-Modul rausgeworfen, über den das binary-only Modul sich an den Kernel anhängen kann.
Der Entwickler des Moduls heult jetzt rum, das sein Modul dann zum 2. Klasse Modul degradiert würde, weil es nur als extern verwaltetes Modul verteilt werden könnte, aber nicht im Kerneltree direkt - denn ohne den Hook kann ja sein binary-only Modul nicht geladen werden. Aus Trotz wirft er die Brocken hin und will das Modul garnicht mehr unterstützen.
Wo ist jetzt der Denkfehler? Bei den Kernel-Entwicklern, die binar-only Module ablehnen und auch keine Backdoors für binary-only Module im Kernel wollen? Wohl kaum.
Der Modulentwickler könnte einfach sein Modul ausserhalb des Kernels weiter betreiben und verteilen. Er kann nur nicht mit dem Hook direkt im Kernel verteilt werden. Er könnte Kernel-Patches verteilen, die den Hook in den Kernelsource patchen. Beide Möglichkeiten lehnt er ab.
Solche oder ähnliche Diskussionen kommen immer wieder hoch, wenn einzelne Entwickler mit ihrer tollen Idee scheitern - und ja, manchmal kommt das Scheitern erst nach ein paar Jahren, weil vorige Maintainer das ganze lockerer gesehen haben. Aber die binary-only Module im Linux-Kernel sind ein ständiges Ärgernis: nicht nur das man sie nicht reparieren kann, weil man den Source nicht hat. Man kann auch keine Security Reviews machen. Und sorry, aber Hooks über die sich unprüfbare binäre Module in den Kernel einklinken können, will ein anständiger Admin eh nicht auf seinem System.
Letzendlich läuft das ganze darauf hinaus, ob Linux jede Hardware unterstützen muss, auch wenn es keine Open Source Treiber für diese Hardware gibt. Das Linux auch proprietäre Schnittstellen bedienen kann, ist klar - einfach Subsysteme ausserhalb des Kernels entwickeln und in den Kernel integrieren. Der Support dafür ist im Kernel drin. Aber muss der Kernel selber solche Module unterstützen?
Meiner Meinung nach nein. Es ist natürlich eine Degradierung von Modulen mit rein binären Anteilen, wenn diese nicht im Kernel mitverteilt werden können. Aber Module mit rein binären Anteilen sind sowieso schon Module zweiter Klasse in einem Open Source System.
Klar, für den Anwender ist es unter Umständen komplizierter (wobei es z.B. bei Debian GNU/Linux ziemlich trivial ist, Modulsubsysteme zum Kernel dazu zu installieren), aber es kann kaum das Ziel eines Open Source Systems sein, seine eigenen Grundsätze aufzuweichen um etwas einfacher zu machen, das gar nicht im Fokus dieses Systems liegt.
Die wirkliche Ursache in dem Problem liegt nicht im Verhalten der Linux Subsystem Maintainer. Die wirkliche Ursache liegt in der Sturheit von Phillips, Teile des Treibers nicht freigeben zu wollen.
Das der Modul-Autor jetzt auf verbrannte Erde macht (löschen der Downloads, löschen der Mailbox, löschen der Sourcen, der FAQ etc.) beweist nur, das er es nicht kapiert hat. Nunja, irgendjemand anderes wird vermutlich den Source und das ganze Geraffel nehmen und weiter betreiben - vermutlich ausserhalb des Kernels. Auch das hat der Autor nicht kapiert. Statt dessen spielt er Trotzköpfchen.
Hier gibts den Originalartikel.
