Kernel- und Treiberprogrammierung mit dem künftigen Kernel 2.6

Kernel- und Treiberprogrammierung ist das Thema der neuen Kern-Technik-Serie: Wie schreiben künftige Kernel-Gurus ihr erstes Modul, etwa einen zeichenorientierten Gerätetreiber für Kernel 2.6? Welche Anpassungen sind erforderlich, um einen 2.4-Treiber auf 2.6 zu portieren? Wie realisiert der neue Kernel Hardwarezugriffe? Und welche Werkzeuge und Techniken sind zur Treiberprogrammierung nötig?

An kurzen, abgeschlossenen Beispielen beschreiben die Artikel Technik, Hintergründe und Anwendung. Wer C kennt, mit Betriebssystemen vertraut ist und Basiskenntnisse über Computerhardware besitzt, kann sofort mit den aktuellen Kernelquellen loslegen. Die Struktur der Module, das Kernel-Build-System[3] sowie das Laden und Entladen von Modulen unter der Kernelgeneration 2.6 sind das Thema der ersten Folge.

Module sind die übliche Form bei Kernelerweiterungen. Sie lassen sich zur Laufzeit laden und wieder entladen. Der entscheidende Vorteil: Das Modul belegt - im Gegensatz zu einer statisch eingebundenen Komponente - nur dann kostbare Ressourcen im Kernel, wenn es unbedingt erforderlich ist.

Code im Kernel

Vorab eine Warnung: Die Beispiele in dieser Artikelserie sind Kernel-Code, also Code, der Zugriff auf sämtliche Systemressourcen hat. Anders als bei einer Anwendung ist es sehr einfach möglich, das gesamte System - nicht nur eine Applikation - zum Absturz zu bringen. Programmierer sollten daher sehr sorgfältig vorgehen, auf so manchen Reboot müssen sie sich dennoch einstellen.

Beim Programmieren sind kaum Unterschiede zwischen dem Entwickeln von Anwendungssoftware und Kernelerweiterungen (zum Beispiel Treiber) festzustellen. Bemerkenswert ist, dass der Entwickler kein eigenständiges Stück Software schreibt, sondern eine zusätzliche Komponente für ein bestehendes und sogar laufendes Programm, den Kernel. Da muss der schnelle Griff zu Funktionen aus der C-Standardbibliothek unterbleiben. Gleitkomma-Operationen sind generell tabu.

Die Kernelentwickler haben viel getan, um die Unterschiede zwischen Kernel- und Anwendungsprogrammierung unsichtbar werden zu lassen. Dass Funktionsaufrufe vielfach Makros sind oder sich dahinter gar Assembler-Code verbirgt, erfährt der Entwickler erst, wenn er in Kernelcode und Headerdateien stöbert. Zum Programmierstil sei auf das sehr lesenswerte Dokument "Linux kernel coding style"[4] verwiesen; es ist auch in den Kernelquellen unter »Documentation/CodingStyle« zu finden. Insbesondere der Anfang könnte dem einen oder anderen ein Lächeln entlocken. Dass im Kernel Goto-Aufrufe erlaubt und sogar erwünscht sind, mag befremdlich wirken - eine spätere Folge wird dazu mehr erklären.

Starthilfe

Um loslegen zu können, müssen ein aktueller Entwicklerkernel und neue Modutils installiert sein (siehe Kasten "Entwicklerkernel installieren"). Neben dem Kernelimage benötigt jeder Programmierer den zugehörigen Quellcode und - das ist bereits neu - auch die Kernelkonfiguration. Ein heikler Punkt, denn bisher genügten Headerdateien und ein selbst geschriebenes Makefile. Die Konfiguration ist der Preis, der für die außergewöhnliche Skalierbarkeit und Portierbarkeit zu zahlen ist: Der Compiler benötigt unterschiedliche Flags, abhängig davon,

• für welche Plattform er den Kernel übersetzen
  soll,
• ob der Kernel für eine Ein-Prozessor- oder eine
  Mehr-Prozessor-Maschine gedacht ist und
• ob innerhalb des Kernels Unterbrechungen (Preemption)
  zugelassen sind.

Dieses Wissen ist im so genannten Kernel-Build-System hinterlegt. Diese in 2.5 komplett überarbeitete Systemkomponente ist für das Generieren des Kernels und seiner Module zuständig. Um sich darin einzuklinken, muss das Makefile den Pfad zu den konfigurierten Kernelquellen kennen. Linus Torvalds hat festgelegt, dass die Quellen über das Module-Verzeichnis zu finden sein sollen: »/lib/modules/ Version/build/«. Meist ist dies ein Symlink auf das bekannte Directory »/usr/src/linux- Version«.