Kernel

Betriebssystem

Der Kernel von UNIX könnte als das Hauptprogramm des Betriebssystems bezeichnet werden. In der klassischen Variante enthält er alles, was zum Betriebssystem gehört, vom Prozessmanager (dem Scheduler), über Speicherverwaltung, Dateisystem bis hin zu den Gerätetreibern war alles ein einziges Programm. In den Anfangstagen von UNIX lag das Betriebssystem als Source vor und es wurde vom Administrator an die Bedürfnisse seiner Umgebung angepasst. Anschließend wurde es mit dem mitgelieferten C-Compiler übersetzt. Die Konstanten, die das Laufzeitverhalten prägten, wurden an die Einsatzumgebung der Maschine angepasst und die benötigten Treiber ausgewählt und danach ein Kernel gebildet (Eigentlich müsste es korrekt "Kernel bauen" heißen, da es sich vom englischen Wort build herleitet. Inzwischen ist "bilden" bereits so tradiert, dass es nur noch Administratoren mit abgebrochenen Germanistikstudium stört.) Dieser Kernel wurde dann in das Rootverzeichnis gelegt.

Kein Quellcode, kein Compiler

Fast alle großen Hersteller von UNIX liefern heute weder die Quelltexte aus, noch ist ein Compiler im Paket enthalten. Das hat mehrere Gründe. Zum einen ist die Art der Anpassung nicht gerade besonders komfortabel. Das Übersetzen ist eine langwierige Geschichte. Das Ausliefern des Quelltextes möchte man vermeiden, um der Konkurrenz keinen Einblick in die eigenen Fortschritte zu geben und schließlich erhofft man sich durch den Verkauf des Compilers als separatem Paket ein Zusatzgeschäft.

Kernel bilden ist out.

Die meisten Parameter des Betriebssystems können heute dem Betriebssystem mitgeteilt werden, ohne eine Neukompilierung zu veranlassen. Einige Größen wie beispielsweise die Anzahl der Plattenpuffer werden nicht mehr festgelegt, sondern vom Betriebssystem dynamisch gebildet, wenn sie erforderlich sind. Treiber werden nicht mehr in den Kernel integriert, sondern als Module während des Laufs hinzugezogen. Das Bilden des Kernels wird darum auf den meisten UNIX Plattformen durch ein menügesteuertes Systemtool erreicht und hat mit dem Compilieren früherer Zeiten nicht mehr viel zu tun.

Linux wird, allerdings aus anderen Gründen, heute noch mit dem kompletten Quellcode ausgeliefert. Auch ein Compiler wird mitgeliefert, so dass das Bilden des Kernels durch mehrere Aufrufe von make abläuft. Nur wenige Parameter werden allerdings noch durch Ändern von Konstanten im Quellcode angepasst. Normalerweise sind solche Parameter durch Umgebungsvariablen einstellbar. Auch die meisten Treiber werden als Module beim Start geladen. Nur bei einigen exotischen Geräten muss man noch selbst Treiber aktivieren oder deaktivieren. Durch die Möglichkeit, Fähigkeiten des Kernels wegzulassen, kann man allerdings sehr spezialisierte, kleine Kernel bauen, die auch auf schmaler Hardware noch laufen.

Generieren eines Linuxkernels

Das Generieren des Kernels erfolgt durch Aufrufe des Programmes make mit unterschiedlichen Zielen.

make config

Mit make config wird ein Dialog gestartet, in dem man wie in einem Multiple Choice Test beantwortet, welche Bestandteile der neue Kernel haben soll. Nacheinander werden die Bestandteile angeboten. Der Administrator muss entscheiden, ob er die Fähigkeit einbinden will oder nicht, oder als Modul zur Verfügung stellen soll. Es werden schlüssige Voreinstellungen vorgeschlagen und zur Unterstützung gibt es kleine Hilfetexte zu jedem Thema.

make dep

Ein make dep erstellt die Abhängigkeiten aus dem Konfigurationslauf und bereitet vor, welche Dateien für den Kernel gebraucht werden.

make bzImage

Ein make bzImage erzeugt schließlich den Kernel und generiert auch gleich den passenden Booteintrag. Wenn man sich noch nicht so ganz sicher ist, kann man auch erst einmal eine Diskettenversion erzeugen. Der Befehl lautet dann make bzdisk. Vorher sollte eine formatierte Diskette ins Laufwerk gesteckt werden.

Basteleien am Kernel sind durchaus etwas riskant. Die mindesten Sicherheitsvorkehrungen sind eine Sicherungskopie des bisherigen, funktionierenden Kernels und ein Medium (CD oder Diskette), mit dem man das System soweit booten kann, um den gesicherten Kernel wieder an seine ursprüngliche Position zu bringen.

Dynamische Bibliotheken

Dynamische Bibliotheken sparen Platz

Bestimmte immer wiederkehrende Bibliotheken wurden früher statisch jedem UNIX-Programm hinzugebunden. Da es Speicherplatzverschwendung ist, die gleiche Bibliothek in jedem Programm wieder und wieder auf der Platte und hinterher auch im Hauptspeicher zu haben, gibt es dynamische Bibliotheken. Besonders mit der Verwendung grafischer Oberflächen ist es fast unmöglich, alle Bibliotheken statisch zu jeder Anwendung hinzuzuladen.

Im Gegensatz zu anderen Systemen ist es nicht üblich, dass Anwenderprogramme neue Versionen der von ihnen benötigten dynamischen Bibliotheken heimlich installieren. Der Update der Bibliotheken obliegt dem Administrator und das Programm kann seinen Kummer darüber zum Ausdruck bringen, dass eine bestimmte Mindestversion einer Bibliothek nicht vorliegt und gegebenfalls enden. Damit ist auf einfache Weise verhindert, dass Software nicht mehr läuft, weil ein anderes Programm installiert wurde.

Man erkennt dynamische Bibliotheken an der Namensendung .so und sie befinden sich im Normalfall im Verzeichnis /lib oder /usr/lib.

Module

Ursprünglich wurden alle Treiber in den Kernel eingebunden. Wenn es notwendig war, eine andere Konfiguration zu verwenden, wurde halt ein neuer Kernel generiert. Solaris, Linux, FreeBSD und damit MacOS X besitzen ein Modulkonzept, um Treiber separat vom Kernel installieren zu können.

Solaris arbeitet mit einem modularen Kernel

Unter Solaris erlangt man mit dem Befehl modinfo eine Übersicht über die aktuell geladenen Module. Mit add_drv kann man Treiber hinzufügen und mit rem_drv wieder entfernen. Nach dem Hinzufügen wird durch den Aufruf von drvconfig eine Neukonfiguration des Verzeichnisses /devices durchgeführt. Für Module, die keinen Zugriff auf Gerätedateien brauchen, lauten die Befehle modload und modunload.¹)

FreeBSD und MacOS X

FreeBSD verwendet die Kommandos kldload und kldunload zum Einbinden und Entfernen von Modulen. kldstat gibt eine Übersicht. MacOS X erbt diese Eigenschaften von FreeBSD und nennt die Kommandos kmodload, kmodunload und kmodstat.

# block dev aliases alias block-major-1 rd alias block-major-2 floppy alias block-major-3 off alias block-major-7 loop ... alias char-major-6 lp alias char-major-9 st

Mit der Anweisung options kann einem Modul Parameter übergeben werden. Im folgenden Beispiel wird der Soundkarte cs4232 IO-Adresse, Interrupt und DMA-Kanäle mitgegeben.

options cs4232 io=0x534 irq=5 dma=1 dma2=0 mpuio=0x330 mpuirq=9

Mit den Anweisungen post-install und pre-install kann festgelegt werden, welche Treiber vorher oder nachher installiert oder deinstalliert werden müssen.

¹ vgl. Nemeth, Evi / Snyder, Garth / Seebass, Scott / Hein, Trent R.: UNIX Systemverwaltung. MarktTechnik - Prentice Hall, 2001, S. 334f.

Diese Seite basiert auf Inhalten aus dem Buch Arnold Willemer: Wie werde ich UNIX-Guru
Verlagsrechte bei galileo computing

Homepage