Betriebssysteme · Institut für Systemarchitektur · Fakultät Informatik · TU Dresden

Seminar Ausgewählte Betriebssysteme




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.
  1. Grundlagen
  2. 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)

  3. Hardwareinteraktion
  4. 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

  5. Testumgebung
  6. 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!").

  7. Referenzen
  8. Anforderungen
  9. 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.
Michael Peter
20. Jul 2004
· Copyright © 2001-2022 Operating Systems Group, TU Dresden | Impressum ·