Login


 
Newsletter
Werbung
Di, 23. Oktober 2012, 13:26

Software::Kernel

Kernel: Streit um EXPORT_SYMBOL_GPL

Ein von Nvidia übermittelter Patch zur Nutzung von Shared-DMA-Buffers im Kernel sorgt für Zwist in der Kernel-Gemeinschaft. Während einige Entwickler die Änderung als Versuch sehen, die Lizenz des Codes zu ändern, sehen andere die Änderung als einen notwendigen Schritt, um eine noch recht junge Architektur auch proprietären Herstellern zugänglich zu machen.

Tux, das Linux-Maskottchen

Larry Ewing

Tux, das Linux-Maskottchen

Vier Monate ist es her, als Linus Torvalds unter dem Beifall zahlreicher Anwender medienwirksam Nvidia ein mürrisches »Fuck you« zuwarf und dem Unternehmen mangelnde Kooperation vorwarf. Stein des Anstoßes war unter anderem der mangelnde Wille seitens Nvidia, die Optimus-Technologie adäquat unter Linux zu unterstützen, was offenbar nicht nur den Linux-Gründer, sondern auch zahlreiche Anwender zur Weißglut bringt.

Optimus ist der Nachfolger der sogenannten »Hybrid-Power« oder Hybrid-SLI-Technologie, bei welcher der Anwender eine zweite Grafikkarte manuell hinzuschalten oder die Chipsatz-GPU im 3D-Modus ganz abschalten lassen kann. Bei Optimus geht die Technologie noch weiter. So schaltet Nvidia bei Optimus bei Bedarf automatisch eine leistungsstärkere Grafikkarte zu der internen hinzu, sofern die Ressourcen des regulären Chips nicht mehr für ein Rendering ausreichen. Dies führt vor allem auf mobilen Geräten zu massiven Einsparungen und zu längeren Akku-Laufzeiten.

Um das Vorhaben zu realisieren, bedient sich der Hersteller diverser Techniken. Ist eine zweite Grafikkarte aktiv, schreibt sie die Bildinformationen in den Speicher der internen Grafikkarte, welche nur für die Ausgabe des Bildes zuständig ist. So kann zwischen den beiden Grafikkarten umgeschaltet werden. Die Voraussetzung für einen reibungslosen Ablauf stellt allerdings die Möglichkeit dar, dass zwei Systeme gleichzeitig auf einen DMA-Buffer zugreifen können. Unter Linux ermöglicht den Vorgang eine Sammlung von Funktionen, die Sumit Semwal vor knapp einem Jahr implementierte. Die dma_buf_* benannten Funktionen stellen die Grundfunktionalität bereit, um gemeinsame DMA-Strukturen zu erstellen, zu verwalten und zu adressieren. Doch gerade diese Funktionen sind nun seit zwei Wochen Gegenstand eines Streits zwischen verschiedenen prominenten Kernelentwicklern.

Stein des Anstoßes stellt ein Patch des Nvidia-Entwicklers Robert Morell dar, der vorschlug, die als EXPORT_SYMBOL_GPL() exportierten Symbole der Shared-DMA-Buff-Architektur in die regulären EXPORT_SYMBOL()-Exportrichtlinien zu ändern. EXPORT_SYMBOL_GPL() wurde vor geraumer Zeit auf Wunsch mancher Entwickler implementiert, die es nicht wünschten, dass ihre Bibliotheken von proprietären Treibern genutzt werden. Über die Sinnhaftigkeit der Richtlinie wird seitdem gestritten, denn manche Entwickler sehen keine Notwendigkeit für eine dedizierte Nennung von exportierten Funktionen. Bereits das Kombinieren von unfreien und freien Komponenten stellt nach Meinung mancher einen Verstoß gegen die GPL dar. Eine explizite Nennung sei zwar gut gemeint, doch nicht wirklich notwendig. Doch auch hier - wie bei vielen Angelegenheiten in der Linux-Gemeinschaft - herrscht keine Einigkeit über die Definition, weshalb EXPORT_SYMBOL_GPL() oftmals dazu verwendet wird, entweder den Wunsch nach der Lizenzeinhaltung zu bekräftigen, oder aber auch als Abwehr, um proprietären Systemen oder Treibern keinen Zugriff auf wichtige Bereiche des Kernels zu ermöglichen.

Dementsprechend hagelte es Kritik, als Morell seinen Patch auf der Liste des Kernel-Projektes vorstellte. Sowohl der Betreuer des Video4Linux/DVB-Subsystems, Mauro Carvalho Chehab, als auch die Linux-Ikone Alan Cox lehnten die Änderungen ab. Cox argumentiert, dass eine Entfernung der Export-Richtlinien die Zustimmung aller Rechteinhaber des entsprechenden Codes benötige. Chehab dagegen verweist auf eine frühere Diskussion, in der er sich gegen eine ähnliche Änderung aussprach und damit argumentierte, dass alle Treiber, die manche hardwarenahen Funktionen nutzen, vollständig offen sein müssen, um Probleme bereits im Quellcode zu erkennen und zu eliminieren. Dem entsprechend sollten nur GPL-lizenzierte Treiber manche Funktionalität des Kernels nutzen.

So klar, wie Cox und Chehab die Sachlage sehen, scheint sie allerdings nicht zu sein. Sowohl der in X.org-Kreisen bekannte Rob Clark, auf dessen Arbeit die Shared-DMA-Buffer-Architektur fußt, als auch der ehemalige IVTV-Betreuer Hans Verkuil sehen in der Änderung eine logische Konsequenz aus den kommenden Änderungen unter Linux. Beide verweisen darauf, dass der Sinn der Shared-DMA-Buffers eine so genannte »Zero-Copy-Pipeline« darstellt, die auch in DRI3/DRI-Next zum Einsatz kommen soll. Betrachtet man, dass unter Linux gleich mehrere proprietäre DRM-Treiber diese Funktionalität brauchen, sollte der Änderung der Exportrichtlinie zugestimmt werden - andernfalls laufen die Entwickler Gefahr, dass das Gros der proprietären Treiberhersteller eigene APIs kreiert, was sowohl dem Sinn der Shared-DMA-Buffers als auch der eigentlichen Problembehandlung zuwider läuft.

Zu einem ähnlichen Standpunkt kommt auch der Betreuer der DRM- und AGPGART-Subsysteme, Dave Airlie. Im Gegensatz zu Cox vertritt der prominente Hacker allerdings die Meinung, dass die Änderung der Export-Richtlinien keine Relizenzierung des Codes nach sich ziehen muss, sondern lediglich eine reguläre Änderung darstelle. Laut Airlie wird der eigentliche Code auch nach der Änderung weiterhin unter den Bedingungen der GNU GPLv2 vertrieben, was sowohl vom Autor als auch von den Kernelentwicklern beabsichtigt war. Eine explizite Erlaubnis der Rechteinhaber sei deshalb nicht notwendig.

Zahlreiche Wortmeldungen später dreht sich die Diskussion nun vorwiegend um ideologische Gründe und weniger um technische Aspekte, was im Kontext der ursprünglichen Freigabe überrascht. Denn der von Semwal ursprünglich vorgestellte Patch nutzte EXPORT_SYMBOL() und wurde erst auf Bestreben einzelner geändert. Die damaligen Gründe: Es sollte proprietären Treibern verwehrt werden, die neue Funktionalität zu nutzen.

Werbung
Pro-Linux
Pro-Linux @Twitter
Neue Nachrichten
Werbung