Linux - Wegweiser zur Installation & Konfiguration, 3. Auflage Online-Version Copyright © 2000 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser zur Installation & Konfiguration oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Ladbare Gerätetreiber

Es hat sich eingebürgert, Gerätetreiber direkt in den Kernel einzubinden, und mehrere Gründe sprechen dafür. Erstens benötigen fast alle Treiber den speziellen Zugriff auf die Hardware, der ihnen als Bestandteil des Kernel-Codes zur Verfügung steht. Dieser Zugriff auf die Hardware ist mit einem Anwenderprogramm nicht ohne weiteres zu realisieren. Außerdem lassen sich Gerätetreiber als Teil des Kernels viel einfacher implementieren - solche Treiber haben vollen Zugriff auf die Datenstrukturen und die anderen Routinen des Kernels, die sie jederzeit aufrufen können.

Allerdings gibt es mehrere Probleme mit einem derart zusammengesetzten Kernel, der alle Treiber enthält. Zunächst muß der Systemverwalter einen neuen Kernel erstellen, um bestimmte Gerätetreiber einzubinden oder zu entfernen - wir haben dies im vorherigen Abschnitt besprochen. Außerdem verführt diese Vorgehensweise die Programmierer von Treibern zu nachlässiger Arbeit; nichts kann einen Programmierer davon abhalten, Code zu schreiben, der nicht streng modular aufgebaut ist - zum Beispiel Code, der direkt auf Daten zugreift, die zu anderen Teilen des Kernels gehören. Dieses Problem wird durch die kooperative Arbeitsweise, in der der Linux-Kernel entsteht, noch verstärkt, und nicht alle Teile des Codes sind so modular angelegt, wie sie sein sollten. Dies kann die Pflege und das Debuggen des Codes erschweren.

Um sich von dieser Vorgehensweise zu befreien, unterstützt der Linux-Kernel ladbare Gerätetreiber - das sind Treiber, die zur Laufzeit mit bestimmten Befehlen in den Speicher geladen oder von dort entfernt werden. Solche Treiber sind immer noch ein Teil des Kernels, aber sie werden getrennt kompiliert und erst durch das Laden aktiviert. Ladbare Gerätetreiber (oder Module) werden im allgemeinen mittels einiger Befehle in den rc-Skripten, die beim Booten aufgerufen werden, in den Speicher geladen.

Module bieten eine sauber definierte Schnittstelle für das Schreiben von Treibern. Sie müssen bis zu einem gewissen Grad modular sein und bestimmte Programmierkonventionen einhalten. (Beachten Sie aber, daß ein Programmierer diese Konventionen trotzdem mißachten und nichtmodularen Code schreiben kann. Nach dem Laden kann so ein Modul denselben Schaden anrichten, als ob es direkt in den Kernel eingebunden wäre.) Die Verwendung von Modulen vereinfacht das Debuggen von Treibern - Sie können ein Modul einfach entladen, es neu kompilieren und wieder laden, ohne daß das System neu gestartet oder der Kernel komplett neu kompiliert werden muß. Module können außer für Gerätetreiber auch für andere Teile des Kernels benutzt werden, etwa die verschiedenen Dateisysteme.

SUnter Linux sind die meisten Gerätetreiber und ein großer Teil sonstiger Kernel-Funktionalität in Form von Modulen implementiert. Einer der bekanntesten ist der »Floppy-Streamer«-Treiber ftape für Bandlaufwerke, die direkt an den Floppy-Controller angeschlossen werden, wie zum Beispiel die Modelle Memory Jumbo 120

Sie brauchen zunächst das Paket modules, in dem die Befehle zum Laden und Entladen von Modulen enthalten sind. Auf den FTP-Servern ist das meistens die Datei modules.tar.gz in dem Verzeichnis, in dem auch die Kernel-Quellen stehen. Dieses Paket enthält die Befehle insmod, modprobe, rmmod und lsmod. In den meisten Linux-Distributionen sind diese Befehle bereits vorhanden (in /sbin); falls sie bei Ihnen schon installiert sind, brauchen Sie das modules-Paket wahrscheinlich nicht mehr. Trotzdem kann es nicht schaden, dieses Paket zu besorgen und die Befehle neu zu kompilieren, damit Sie auf jeden Fall die aktuelle Version haben.

Zum Kompilieren dieser Befehle entpacken Sie zunächst modules.tar.gz (zum Beispiel in einem Unterverzeichnis zu /usr/src). Befolgen Sie die mitgelieferten Installationshinweise; in der Regel brauchen Sie nur als root zuerst make und dann make install aufzurufen. Die drei Befehle werden dann in /sbin aufrufbereit installiert.

Ein Modul ist nichts weiter als eine einzelne Objektdatei, die den kompletten Treibercode enthält. Das Modul ftape könnte also ftape.o heißen. Auf vielen Systemen stehen die Module im Verzeichnis /lib/modules/kernelversion, in dem Sie verschiedene Verzeichnisse mit den einzelnen Modultypen finden. Beispielsweise stehen die Module für einen 2.2.2-Kernel unter /lib/modules/2.2.2. Es ist nicht unwahrscheinlich, daß es bereits eine Reihe von Modulen auf Ihrem System gibt; sehen Sie also einmal im entsprechenden Verzeichnis nach.

Module können entweder aus den Kernel-Quellen kommen oder extern sein. Ersteres ist der Fall bei Gerätetreibern, Dateisystemen und anderen Funktionalitäten, die häufig benötigt und als Bestandteil der offiziellen Kernel-Quellen gepflegt werden. Die Verwendung dieser Module ist sehr einfach; geben Sie einfach während der Ausführung von make config, make menuconfig oder make xconfig ein m ein, um ein bestimmtes Feature als Modul zu bauen. Machen Sie das bei allen gewünschten Modulen so. Führen Sie dann nach dem make zImage-Schritt die Befehle make modules und make modules_install aus. Dadurch werden die Module kompiliert und in /lib/modules/kernelversion installiert. Aus weiter unten beschriebenen Gründen sollten Sie danach den Befehl depmod -a ausführen, um die Modulabhängigkeiten zu aktualisieren.

Neue Module, die noch kein Bestandteil der offiziellen Kernel-Quellen oder einfach zu esoterisch sind, um in den Kernel-Quellen zu landen (wie beispielsweise ein Gerätetreiber für selbstgebaute Hardware, die nicht einfach so zu kaufen ist), können als freistehende, externe Module verfügbar sein. Entpacken Sie die Archivdatei dieses Moduls, kompilieren Sie es anhand der hoffentlich enthaltenen Anweisungen, und kopieren Sie das resultierende Modul in das passende Unterverzeichnis von /lib/modules/kernelversion. Bei einigen Modulen gibt es vielleicht auch ein Installationsskript, oder Sie können make install verwenden, um den letzten Schritt auszuführen.

Sobald Sie ein fertig kompiliertes Modul haben (entweder aus den Kernel-Quellen oder extern), laden Sie es mit dem Befehl

insmod Modul



   

wobei Modul der Name der Objektdatei des Moduls ist. Ein Beispiel:

insmod /lib/modules/2.2.2/char/ftape.o



   

installiert den Treiber ftape, wenn dieser in der Datei ftape.o enthalten ist.

Wenn ein Modul installiert wird, gibt es wahrscheinlich auf der Konsole (und in die Logdateien) einige Informationen aus, die anzeigen, daß das Modul initialisiert ist. Der Treiber ftape könnte etwa folgendes ausgeben:

ftape v1.14 29/10/94 (c) 1993, 1994 Bas Laarhoven (bas@vimec.nl)
  QIC-117 driver for QIC-40 and QIC-80 tape drives
[000] kernel-interface.c (init_module) - installing QIC-117 ftape driver....
[001] kernel-interface.c (init_module) - 3 tape_buffers @ 001B8000.
[002]  calibr.c (time_inb) - inb() duration: 1436 nsec.
[003]  calibr.c (calibrate) - TC for `udelay()' = 2944 nsec (at 2049 counts).
[004]  calibr.c (calibrate) - TC for `fdc_wait()' = 2857 nsec (at 2049 counts).



   

Der genaue Text der Meldung hängt natürlich vom Modul ab. Es sollte immer eine ausführliche Dokumentation dazugehören, in der beschrieben wird, was das Modul tut und wie Sie es im Problemfall debuggen müssen.

Es kann sein, daß insmod Ihnen mitteilt, daß es das Modul nicht in den Kernel laden kann, weil »Symbole fehlen«. Das bedeutet, daß das Modul, das Sie laden wollen, Funktionen aus einem anderen Teil des Kernels benötigt, der weder in den Kernel kompiliert worden ist, noch in einem bereits geladenen Modul enthalten ist. Sie könnten jetzt versuchen herauszufinden, welches Modul diese Funktionen enthält, dieses Modul zuerst mit insmod laden und dann das eigentliche Modul noch einmal zu laden versuchen. Damit kommen Sie am Ende zum Ziel, aber das kann reichlich mühsam sein, und wir würden nicht mit Linux arbeiten, wenn es nicht einen einfacheren Weg gäbe.

Zunächst benötigen Sie eine Moduldatenbank in der Datei Namens /lib/modules/ kernelversion/modules.dep. Diese können Sie mit dem Befehl

depmod -a



   

erzeugen. Dabei werden alle vorhandenen Module daraufhin überprüft, ob sie irgendwelche anderen Module benötigen. Wenn diese Datenbank einmal vorhanden ist, können Sie einfach den Befehl insmod durch den Befehl modprobe ersetzen, der die Moduldatenbank abfragt und alle eventuell notwendigen Module zuerst lädt, bevor er das angeforderte Modul selbst lädt. Beispielsweise enthält unsere Datei modules.dep neben anderen die folgende Zeile:

/lib/modules/2.0.35/misc/hisax.o:	      /lib/modules/2.0.35/misc/isdn.o



   

Das bedeutet, daß zum Laden des Moduls hisax (ein Gerätetreiber für eine Reihe von ISDN-Karten) zunächst das Modul isdn geladen sein muß. Wenn wir jetzt das Modul hisax mit modprobe laden, dann erkennt modprobe diese Abhängigkeit und lädt das isdn-Modul (dieses Beispiel ist etwas vereinfacht, da das Modul hisax noch weitere Parameter benötigt).

Manche Module benötigen sogenannte Modulparameter. Beispielsweise kann es sein, daß einem Gerätetreiber eine IRQ-Leitung zugewiesen werden muß. Diese Parameter können Sie in der Form parametername=parameterwert zuweisen, sowohl bei insmod als auch bei modprobe. Im folgenden Beispiel werden mehrere Parameter an das Modul hisax übergeben:

tigger # modprobe hisax type=3 protocol=2 io=0x280 irq=10



   

Die Dokumentation zu den einzelnen Modulen sollte angeben, welche Parameter das Modul kennt.

Eine Warnung zur Verwendung von Modulen, wenn Sie die Debian-Distribution benutzen: Debian verwendet eine Datei /etc/modules, die die Module angibt, die bereits beim Booten geladen werden sollen. Wenn ein Modul, das Sie gar nicht haben wollen, immer wieder auftaucht, dann sehen Sie nach, ob es vielleicht hier steht.

Mit lsmod können Sie die geladenen Treiber auflisten:

rutabaga%     lsmod 
Module:       #pages:     	 Used by
ftape         40 



   

Auch der Speicherplatzbedarf des Moduls wird angezeigt; unter Linux ist eine Speicherseite (page) vier KB groß. Der Treiber ftape belegt also 160 KB. Wenn andere Module von diesem abhängig sind, dann stehen diese in der dritten Spalte.

Mit dem Befehl rmmod läßt sich ein Modul wieder entladen:

rmmod ftape



   

rmmod bekommt als Argument den Namen des Treibers mit, wie er in der lsmod-Liste erscheint.

Sobald die Module zu Ihrer Zufriedenheit funktionieren, können Sie den entsprechenden insmod-Befehl in eines der rc-Skripten einfügen, die beim Booten ausgeführt werden. Eventuell ist in einem der Skripten auch schon eine Stelle vorgegeben, an der insmod-Befehle plaziert werden können - das hängt von Ihrer Distribution ab.

Zur Zeit müssen Sie ein Modul jedesmal neu kompilieren, wenn Sie eine neue Kernel-Version oder einen höheren Patch-Level einspielen. (Wenn Sie den Kernel lediglich in derselben Version neu kompilieren, brauchen Sie das Modul nicht gleichzeitig zu aktualisieren.) Man macht das, um sicherzustellen, daß ein Modul zu der neuen Kernel-Version kompatibel bleibt. Wenn Sie versuchen, ein Modul mit einer Kernel-Version zu laden, für die es nicht kompiliert wurde, erhalten Sie eine Fehlermeldung von insmod, und das Modul wird nicht geladen. Bei der Neukompilierung eines Moduls müssen Sie mit dem Kernel arbeiten, unter dem das Modul benutzt werden soll. Aktualisieren Sie deshalb bei einem Update des Systems zuerst den Kernel, und starten Sie das System neu, bevor Sie die Module neu kompilieren und laden.

Module automatisch laden

Ein besonders praktisches Feature ist der sogenannte Kernel-Dämon kerneld. Mit Hilfe des Kernel-Dämons kann der Kernel fehlende Gerätetreiber oder andere Module automatisch und ohne Zutun des Benutzers laden und - wenn sie nicht mehr gebraucht werden - nach einer gewissen Zeitspanne (60 Sekunden) auch wieder automatisch entladen.

Voraussetzung für die Verwendung des Kernel-Dämons ist die Aktivierung zweier Optionen während des make config-Laufs der Kernel-Konfiguration. Sie benötigen sowohl die »System V«-Interprozeßkommunikation wie auch die Unterstützung für den kerneld selbst. Außerdem muß der kerneld während des Systemstarts aus einer der rc-Dateien gestartet werden. Neuere Distributionen sollten das automatisch einstellen.

Module, die andere Module benötigen, müssen korrekt mit ihren Abhängigkeiten in der Datei /lib/modules/kernelversion/modules.dep eingetragen werden. Außerdem muß es für die Major und Minor Numbers Aliasnamen in /etc/conf.modules geben. Lesen Sie hierzu die Dokumentation aus dem modules-Paket.

Wenn ein Modul nicht von Hand, sondern durch den kerneld geladen wurde, erscheint es bei der Auflistung mit lsmod mit dem Zusatz (autoclean). Das bedeutet, daß der kerneld das Modul wieder entfernen wird, wenn es länger als eine Minute nicht gebraucht wurde.

Noch ein letztes Wort zu kerneld: In den neuesten Kerneln wird kerneld nicht mehr benötigt, weil es jetzt ein neues Kernel-Feature namens kmod gibt, das dieselben Aufgaben übernimmt (indem es einen separaten Kernel-Thread startet, der die Module bei Bedarf lädt). Es schadet aber nicht, kerneld weiterhin aktiviert zu haben.

Weitere Informationen zum Linux - Wegweiser zur Installation & Konfiguration

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center