Treiberdesign
... [ Seminar Linux und Apache ]
... [ Thema Gerätetreiber unter Linux 2.4 ]
... [ Device File System ] ...
Grundlegende Konzepte bei der Programmierung
Treiber stellen Mechanismen zur Verfügung, keine policy (Richtlinien). Diese Trennung wird in Unix-Systemen häufig und gern praktiziert.
Fast jedes Problem beim Programmieren kann in zwei Teile gespalten werden:
welche Fähigkeiten überhaupt zur Verfügung gestellt werden (Mechanismus) und wie diese benutzt
werden können (Policy).
Ein Treiber macht Hardware nur verfügbar; WIE die Hardware benutzt wird, ist allein Sache
der Applikationen.
Der Floppy-Treiber z.B. hat keinerlei Policies, seine Aufgabe ist es, die Diskette als fortlaufendes Array von Datenblöcken darzustellen. Wer auf die Diskette zugreifen darf, ob das direkt oder über ein Dateisystem zulässig ist usw., wird auf höheren Levels entschieden.
Verhaltensrichtlinien sollten weitestgehend vermieden werden, damit verschiedene Umgebungen die Hardware
nutzen können.
Auf Policies zu verzichten, ist aber nicht immer möglich.
Ein digitaler I/O-Treiber kann z.B. nur byte-weisen Zugriff auf die Hardware erlauben, um den Zusatzcode zu vermeiden, der für die Behandlung von einzelnen Bits notwendig ist.
Der Treiber kann auch als Software-Schicht zwischen der Applikation und dem Gerät betrachtet werden.
Dadurch kann der Programmierer entscheiden, wie ein Gerät dargestellt wird.
Mehrere Treiber können unterschiedliche Fähigkeiten anbieten, auch für das gleiche Gerät.
Dabei sollten folgende Aspekte im Auge behalten werden:
- Verhalten bei gleichzeitiger Benutzung durch mehrere Programme
- Einfachheit des Treiberprogramms, um dadurch Fehler zu vermeiden
- Verhältnis von Zeitaufwand und Anzahl der angebotenen Optionen
Treiber ohne Policies haben u.a. folgende Eigenschaften:
- Unterstützung von synchronen und asynchronen Operationen
- sie können mehrfach geöffnet werden
- sie können alle Fähigkeiten der Hardware voll ausnutzen
- Softwareschichten können Dinge nicht vereinfachen oder an Policies gebundene
Operationen zur Verfügung stellen
- sie arbeiten im Hinblick auf den Endbenutzer besser
- sie sind einfacher zu schreiben und zu warten
Viele Treiber werden allerdings gemeinsam mit Benutzerprogrammen veröffentlicht, um bei der Konfiguration und beim Zugriff auf das Endgerät zu helfen (z.B. tunelp oder cardctl).
Um gute Treiber zu entwickeln, reicht es nicht aus, Hardware systemkonforn anzusprechen. Ein geeignetes Treiberinterface zu entwickeln ist die eigentliche Aufgabe.
Die Hardware muß intuitiv bedient werden können und in einem Fehlerfall in einen sicheren Zustand überführt werden.
Wenn man mit dem Design eines Treibers beginnt, gibt es Richtlinien, an denen man sich orientieren kann/sollte.
Aufgaben bei der Treiberkonzipierung:
- Abbildung von Funktionalität bzw. semantischer Bedeutung auf logische Geräte
- Festlegung der logischen Geräte und deren Funktionalität
- Festlegung der Zugriffsarten (z.B. non-blocking, blocking)
- Festlegung der unterstützten Systemcalls (lesen, schreiben, ioctl, poll)
- Festlegung der Zugriffsrechte (wieviele Threads, Applikationen dürfen zu welchen Zeitpunkten wie auf das Gerät zugreifen)
- Festlegung von IO-Controls
Folgende Eigenschaften sollte ein Treiber besitzen:
- Das Gerät kann mit den vorhandenen Standardprogrammen (cat oder echo) angesprochen werden.
- Sparsamste Verwendung von IO-Controls.
- Automatische Detection der Hardware- und Konfigurationsparameter.
- Vollständige Abbildung des Applikationsinterfaces (also die Realisierung aller Systemcalls wie beispielsweise poll).
Ein Treiber sollte ohne spezielle Software auskommen und sich mit Systemprogrammen bedienen lassen.
... [ Seminar Linux und Apache]
... [ Thema Gerätetreiber unter Linux 2.4]
... [ nach oben ]
... [ Device File System ]
...