DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER

Die hier archivierte Mail kann, muss sich aber nicht auf den Themenkomplex von Oekonux beziehen.

Insbesondere kann nicht geschlossen werden, dass die hier geäußerten Inhalte etwas mit dem Projekt Oekonux oder irgendeiner TeilnehmerIn zu tun haben.

DISCLAIMER DISCLAIMER DISCLAIMER DISCLAIMER

Message 00519 [Homepage] [Navigation]
Thread: choxT00519 Message: 1/2 L0 [In date index] [In thread index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

[chox] Endlich eine Lösung für das Treiber- Problem bei Linux?



Binäre Treiber als Universallösung? 
Gesendet von demon am Mi, 26. Nov 2003 um 13:39 

http://www.pro-linux.de/news/2[PHONE NUMBER REMOVED].html
 
  Geht es nach dem Willen von SciTech, so dürfte die »Treiber-Krise« schon 
bald der Vergangenheit angehören - binäre Treiber sollen die Lösung sein.

Eine brauchbare Unterstützung von Hardware-Komponenten sollte eine 
Selbstverständlichkeit sein. Dass die triste Realität den Wünschen in den 
seltensten Fällen entspricht und viele Hardware-Hersteller Linux eher 
stiefmütterlich behandeln, hat jeder Verfechter des offenen Systems erkannt. 
Petitionen, wie die erst kürzlich gestartete Petition für bessere Matrox 
Parhelia-Treiber, sind keine Seltenheit, sondern stellen vielmehr eine 
bittere Wahrheit dar. Geht es nun nach SciTech, so darf die »Treiber-Krise« 
getrost vergessen werden.


Die unter dem Namen System Neutral Access Protocol (»SNAP«) vorgestellte 
Lösung stellt einen Hardware Abstraction Layer (HAL) dar. Die Idee ist 
keinesfalls neu und und bereits in anderen Produkten implementiert. Ein 
Treiber, welcher streng genommenen die Kommunikation zwischen der Hardware 
und dem Betriebssystem regelt, verfügt im Idealfall über zwei 
Schnittstellenarten. Zum einen bietet ein Treiber eine Schnittstelle zum 
Betriebsystem hin, die je nach System mehr oder oder weniger kompliziert sein 
kann, und zum anderen eine Schnittstelle zur Hardware, mittels derer 
Hardware-Zugriffe realisiert werden können. Bedingt durch die Tatsache, dass 
ein Treiber die Konfiguration, Initialisierung und das Handling einer 
Hardware-Komponente ebenfalls regelt, kann davon ausgegangen werden, dass die 
Mehrzahl des Codes eines Treibers Common-Code darstellt und auf jeder 
Plattform funktionieren sollte. Was liegt also näher, als einen Abstraction 
Layer zwischen den Treiber und dem System zu schalten, so dass dieser nicht 
mehr direkt mit dem System kommuniziert, sondern nur eine einheitliche 
Sprache mit dem Layer »spricht« und dieser die Kommandos an die 
Betriebssystem-API leitet?


Gerade diesen Weg will SNAP einschlagen und stellt Entwicklern einen Hardware 
Abstraction Layer dar. Der Treiber, der bei SNAP »Shell Driver« heißt, liegt 
in Form einer dynamischen Bibliothek (Dynamic Link Library oder »DLL«) vor 
und kommuniziert nicht mehr direkt mit dem System, sondern lediglich mit 
SNAP. Der Vorteil für den User: Ein an SNAP angepasster Treiber muss nur 
einmal geschrieben werden und bedient alle von SNAP unterstützten 
Plattformen. Der mögliche Nachteil: verringerte Geschwindigkeit, auch wenn 
SciTech durch Benchmarks zu beweisen versucht, dass ein Shell Driver durchaus 
performanter sein kann als ein »nativer« Hardwaretreiber.


Das unter der GNU Lesser General Public License (LGPL) veröffentlichte SNAP 
SDK kann ab sofort vom Server des Produzenten für diverse Plattformen, unter 
anderem auch für Linux, Unices, Windows und QNX, heruntergeladen werden. 

_______________________
http://www.oekonux.de/



[English translation]
Thread: choxT00519 Message: 1/2 L0 [In date index] [In thread index]
Message 00519 [Homepage] [Navigation]