|
|
|
|
Winter semester:
Summer semester:
Always:
|
|
|
|
|
|
|
|
Entwicklung eines Linux-Treibers
Der Treiber für den Linux-Kern ab Version 2.6.5 zu schreiben. Da mit
dem neuen Kern sich mehrere Werkzeuge geändert haben, müssen diese
gegebenenfalls auch neu installiert werden.
Weitere Fragen können auf abs2004 diskutiert werden.
- Grundlagen
Im ersten Teil des Treibers besteht aus einem vereinfachten
Gerätemodell (nur ein Gerät). Anstelle der Hardware der seriellen
Schnittstelle wird eine Workqueue als asynchroner
Kommunikationspartner fungieren.
Folgende Anforderungen sind zu erfüllen:
- Das Modul muss kompiliert werden und beim Laden und Entladen
in/aus dem Kern die entsprechenden Initilisierungs-
bzw. Entfernungsroutinen aufrufen. Das Kompilieren eines Kernelmodules
ist auf LWN
beschrieben. Eine Beispielkonfiguration für einen 2.6.5er Kern ist
hier verfügbar.
- Der Treiber muss das von ihm implementierte character device im
Kern registrieren. Der zu unterst
Im Filesystem sind weiterhin die entsprechende
Geräte anzulegen. Das Laden des Modules und das Erstellen der
passenden Gerätedateien soll mit einem Shell-Skript unterstützt
werden.
Das Gerät unterstützt nur open, close, read,write.
- Die Schnittstelle des Treibers zu asynchronen Komponenten sind
zwei Ringpuffer (Ein- und Ausgabe) in denen Daten vorgehalten
werden. Anstelle der später unterstützten seriellen Schnittstelle
übernimmt im ersten Teil eine Workqueue die Rolle des asynchronen
Kommunikationspartners.Die prinzipielle Struktur ist für die beiden
Modelle identisch, so dass einfach zwischen Workqueue und serieller
Schnittstelle gewechselt werden kann.
Die Workqueueimplementierung kann Daten vorerst willkürlich verwerfen
bzw. erzeugen. Die einzige Forderung besteht darin, dass eine gewisse
Raten an Operationen eingehalten wird. Diese könnte z.B. dadurch
geschehen, dass pro Zeiteinheit nur eine bestimmte Menge an Daten aus
den Ringpuffern entfernt bzw. in diese hinzugefügt werden. Für den
Nutzer ist dieses Verhalten sichtbar. Lesen weniger Daten aus vollen
Puffern erfolgt ohne Verzögerung, Lesen aus leeren Puffern blockiert
zeitweise.
- Der Treiber implementiert Teile seiner Funktionalität in einem
Tasklet. Das Tasklet und der Nutzerprozess müssen sich korrekt miteinander synchronisieren.
- Bei Lese- und Schreiboperation wird auf Teile des
Nutzeraddressraumes zugegriffen. Diese Zugriffe müssen so erfolgen,
dass bewußt oder fahrlässig übergebenen Zeiger das System nicht beschädigen können (put_user,get_user)
- Hardwareinteraktion
Im zweiten Teil kommen folgende Punkte hinzu:
- Programmierung der seriellen Schnittstelle
- Interrupts
- procfs
- ioctl
- Unterstützung mehrerer verschiedener Geräte
- Unterbrechungen durch Signale
- Standardkonformes Verhalten
- Testumgebung
vmi_267_drv.tar.bz2 ist ein
VMware 4.5 Image, dass zur Entwicklung genutzt werden kann. Es gibt
zwei accounts root (password: "!root!") und developer (password:
"!developer!").
- Referenzen
- Anforderungen
Genauere Anforderungen werden in den kommenden Tagen nach Absprache mit dem für die Betreuung zuständigen Hiwi an dieser Stelle veröffentlicht.
Als vorläufigen groben Ansatz steht ein
log zur Verfügung.
|