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.
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] |
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] |