Login
Login-Name Passwort


 
Newsletter
Werbung

Mi, 30. August 2006, 12:37

Software::Systemverwaltung

Proprietäre PCI-Treiber für Userspace

Greg Kroah-Hartman stellte auf der Linux-Kernel-Mailingliste (LKML) eine neue Erweiterung vor, die eine Einbindung von proprietären PCI-Treibern im Userspace ermöglichen soll.

Die als »Industrial IO device driver« vorgestellte Lösung ermöglicht proprietären Treibern, die ohne Quellcode ausgeliefert werden, direkt über definierte Schnittstellen Kernelfunktionen aufzurufen. Dabei würden sich für die Hersteller der Erweiterungen keine Nachteile ergeben. Wie das Autorenduo Thomas Gleixner und Benedikt Spranger mit seiner Lösung zu demonstrieren versucht, besteht überhaupt keine Notwendigkeit, proprietäre Treiber direkt in den Kernel einzubinden. Eine Userspace-Lösung würde den Herstellers laut Kroah-Hartman darüber hinaus den Vorteil bringen, dass sie sich nicht oft ändern würde und bestehende Treiber nicht stetig an neue Kernel-Funktionen angepasst werden müssten. Als Beispiel nennt der Hacker den X-Server, der ebenfalls im Userspace betrieben wird und von dort aus auf Hardware zugreift.

Nach Auffassung manch eines Kernel-Entwicklers sind Kernel-Module abgeleitete Werke des Kernels, und für diese schreibt die GPL vor, dass sie unter der gleichen Lizenz wie der Kernel stehen müssen. Die Auslegung der Passage der GPL ist allerdings bei vielen umstritten, doch auch Torvalds vertritt die Meinung, dass alle Treiber, die gegen eine Kernel-API gelinkt sind oder gegen einen Kernel linken, auch unter der GPL stehen müssen. Im Gegensatz zu Userland-Applikationen stellen Treiber in diesem Fall ein »Derivative Work«, eine vom Linuxkernel abgeleitete Software dar, die auch den Lizenzbestimmungen der GPL unterliegen muss.

Für Hersteller proprietärer Treiber würde es also bedeuten, dass sie auch ihre Treiber unter die GPL stellen müssten. Bisher habe zwar niemand versucht, dies zu erzwingen, doch würde auch nach Meinung von Greg Kroah-Hartman »ein einziger Entwickler«, der dies versucht, ausreichen, um die bisherige Praxis zu Fall zu bringen. Dies demonstrierte Kroah-Hartman in einem kleinen Patch, der wichtige Funktionen des Kernels dem Zugriff von nicht-GPL-Modulen entzog und für Diskussionen mit Herstellern proprietärer Treiber sorgte.

Bis vor kurzem haben sich die Entwickler des Kernels strikt geweigert, eine einheitliche API für den Kernel zu erstellen. Erst vor einem Jahr haben diverse japanische Unternehmen Kroah-Hartman einen Vorschlag unterbreitet, der eine weitere Abstraktionsebene im Kernel vorsah, um Treiber und Kernel besser trennen zu können.

Die nun vorgestellte Lösung stellt noch keine endgültige Version dar. Wie Kroah-Hartman schreibt, handelt es sich bei dem Vorschlag um einen vorläufigen Entwurf. Ferner existiert noch keine Dokumentation, die den Zugriff auf die neue Funktion erklären würde. Zudem ist es im Moment noch offen, inwiefern die neue Schnittstelle die Belange der Entwickler befriedigen wird. Vorerst scheint die Lösung lediglich die wichtigsten Funktionen des Kernels zu exportieren, die wohl bei komplexen PCI-Treibern nicht ausreichen werden.

Werbung
Kommentare (Insgesamt: 75 || Alle anzeigen || Kommentieren )
Re[3]: prop pci-treiber (c64, Fr, 1. September 2006)
Re[3]: prop pci-treiber (dgtat, Fr, 1. September 2006)
Re[2]: prop pci-treiber (dgrat, Fr, 1. September 2006)
Re[6]: Na hoffentlich wird das was (Catonga, Fr, 1. September 2006)
Re[2]: Gute Idee (Stefan Betz, Do, 31. August 2006)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung