The Next Generation

Noch in diesem Jahr dürfte Linux den nächsten großen Schritt machen: Der Kernel 2.6 bringt Änderungen, Neuerungen und Verbesserungen an allen Ecken - vom Build-System über den Module Loader bis zum NUMA-Support. Beim Einsatz sind jedoch einige Dinge zu beachten.

11

17.11.2003, 00:00 Uhr

Lesezeit: 30 Min.

c't Magazin

Von

Dr. Oliver Diedrich

Linux verdankt seine Popularität nicht zuletzt dem Umstand, dass es auf nahezu allem läuft, was Nullen von Einsen unterscheiden kann. Ob Desktop-Rechner oder Notebook, ob Embedded Device oder Multiprozessor-Server: Der neue Kernel 2.6 dürfte in allen Einsatzbereichen Verbesserungen bringen. Mobile Anwender profitieren von ACPI und der Unterstützung von Speedstep und PowerNow, große Server von den Native POSIX Threads (NPTL) und NUMA (Non-Uniform Memory Architecture). Ein neuer Scheduler, massive Verbesserungen in den Bereichen I/O und Speicherverwaltung sowie unterbrechbarer Kernelcode sorgen für eine geringere Latenz bei der Abarbeitung von Interrupts und Task-Wechseln. Das ermöglicht nicht nur weiche Echtzeitanwendungen im Embedded-Bereich, sondern auch ein glatteres Sound- und Videostreaming auf dem Desktop. Dank schlankerem Code scheint der Ressourcenbedarf bei all dem nicht gestiegen zu sein, im Gegenteil: Unter hoher Last reagiert das System mit dem neuen Kernel flüssiger.

Während der zwei Jahre dauernden Arbeit am Kernel 2.5 ist kaum ein Subsystem unangetastet geblieben. An vielen Stellen sind zentrale Kernelstrukturen grundlegend überarbeitet oder ganz neu geschrieben worden. Das hat Linux unter anderem ein neues, vereinheitlichtes Gerätemodell beschert, systemimmanente Begrenzungen beseitigt, die Skalierbarkeit verbessert und den Kernelcode insgesamt übersichtlicher, leichter zu pflegen und damit zukunftssicher gemacht.

Nicht alle Neuerungen erreichen mit dem Kernel 2.6 erstmals den Anwender: Linux-Distributoren haben längst einzelne der während der Arbeit am Entwicklerkernel 2.5 entstandenen Neuerungen auf ihre eigenen 2.4er-Kernel zurückportiert - SuSE beispielsweise den ACPI-Code, Red Hat die Native POSIX Threads. Einige neue 2.5er-Features, beispielsweise die Unterstützung der Athlon-64-Prozessoren, sind auch in den offiziellen Kernel 2.4 übernommen worden.

Gerätezoo

Mit der Version 2.6 erhält der Linux-Kernel ein neues, vereinheitlichtes Gerätemodell. Alle Geräte sind intern in einer Liste von kobject-Strukturen repräsentiert, die über ein neues Pseudodateisystem - das "system filesystem" sysfs - dem Anwender zugänglich ist: Nach einem mount -t sysfs none /sys findet man in /sys (fast) alles, was der Kernel über die vorhandenen Geräte und die zugehörigen Gerätetreiber weiß. Wer das sysfs erforschen will: Auf [1|#literatur] stehen einfache Userland-Tools bereit.

Das neue Gerätemodell unterscheidet Busse, Geräte und Klassen. Die Beziehungen zwischen Bussen und Geräten spiegeln die physischen Gegebenheiten im Rechner wider, wobei auch virtuelle Geräte möglich sind. Klassen ordnen die Geräte nach althergebrachten Schemata wie Eingabegeräte, Netzwerk oder TTYs. Diese Unterscheidung zeigt sich auch im Aufbau des sysfs, in das nach und nach die meisten Informationen aus /proc wandern werden: /proc soll sich mittelfristig wieder auf Prozessinformationen beschränken.

Mit dem neuen Gerätemodell verlagert sich viel Wissen über die Hardware aus den einzelnen Treibern in den Kernel. Das verbessert nicht nur Powermanagement und Systemkonfiguration via ACPI, sondern macht es auch möglich, alle Geräte als hot-pluggable zu behandeln: Aus Kernelsicht besteht kein prinzipieller Unterschied zwischen einer PCI-Karte und einem USB-Gerät. Selbst ein Prozessor ist (natürlich nur in SMP-Systemen) im laufenden Betrieb ausbaubar - ein Patch dafür existiert bereits. Insgesamt dürfte das neue Gerätemodell den Umgang mit Hotplug-Geräten aller Art deutlich verbessern.

Natürlich gibt es auch sonst Fortschritte: Linux 2.6 kann USB 2.0 und AGP 3.0 und beherrscht den Umgang mit mehreren AGP-Karten. Der Bluetooth-Support gilt jetzt als stabil; obwohl die einschlägigen Konfigurationsvariablen ihren Namen von CONFIG_BLUEZ_... nach CONFIG_BT_... geändert haben, kommt nach wie vor der Bluez-Stack zum Einsatz. Eine vollständige PnPBIOS-Implementierung soll Plug-and-Play-ISA-Karten in den Griff kriegen. Ganz unproblematisch scheint das aber noch nicht zu sein: Auf einem Sony-Notebook stürzte der Kernel beim Booten ab, wenn die PnPBIOS-Option aktiviert war.

An vielen Stellen sind Limits im Kernel gefallen. Linux 2.6 kennt 4095 (statt 255) Major Devices mit jeweils über einer Million Minor Device Numbers (statt ebenfalls 255). User- und Gruppen-IDs sind von 16 auf 32 Bit Breite gewachsen - nötig für große Authentifizierungsserver. Dank 32-bittiger PIDs ist die Zahl der Prozesse nur noch durch den Speicherausbau begrenzt. Da die CPU-Maske einen eigenen Datentyp erhalten hat und nicht mehr in einer long-Variablen gespeichert wird, sind in der x86-Welt mehr als 32 Prozessoren, auf 64-Bit-Architekturen über 64 CPUs möglich.

Mobil

ACPI-Support ist jetzt ganz offiziell in den Kernel eingezogen und so stabil, dass man ihn auf fast jeder Maschine anschalten kann. Dinge wie Prozessortemperatur und Ladestand des Akkus sollten zumeist korrekt angezeigt werden. Schlafen legen klappt freilich kaum besser als bei unseren letzten Versuchen vor einem Jahr [2|#literatur] - auch mit dem Kernel 2.6 haben wir lediglich Reaktionen zwischen "es passiert gar nichts" über "schläft ein, aber wacht nicht mehr auf" bis zum Totalabsturz erlebt.

Notebook-Besitzer müssen dennoch nicht verzweifeln. Suspend to Disk hat gleich in zwei Spielarten Einzug in den Kernel gehalten (SOFTWARE_SUSPEND und PM_DISK, Letzteres machte bei unseren Versuchen den stabileren Eindruck). Beide sichern den aktuellen Systemzustand ganz unabhängig von APM oder ACPI auf die Platte. Steuern lässt sich der Schlafzustand über das sysfs: echo -n "disk" > /sys/power/disk schickt den Rechner in den Suspend-to-Disk-Zustand.

Zudem kann Linux 2.6 die Taktfrequenz fast aller Mobile-CPUs von Intel (inklusive Pentium-M) und AMD im laufenden Betrieb umschalten. Die Speedstep-Treiber funktionieren recht zuverlässig, der p4-clockmod-Treiber zeigte bei einem Mobile-P4-Notebook ein paar Kinderkrankheiten. Gesteuert wird der cpufreq-Code über die Pseudodateien in /sys/devices/system/cpu/cpun/cpufreq/.

Ein Treiber für Synaptics-Touchpads beschert der Linux-Welt Features, die unter anderen Betriebssystemen längst selbstverständlich sind: Streichen über das Touchpad scrollt im Fenster, ein Tippen in die rechte untere Ecke simuliert den Klick mit der rechten Maustaste et cetera. Um das alles zu nutzen, ist noch ein X11-Treiber nötig [3|#literatur], der auf den Kerneltreibern für PS/2-Mäuse und das Event-Interface aufsetzt.

Für die meisten Anwender längst ein alter Hut, hat jetzt endlich die Advanced Linux Sound Architecture (ALSA) Einzug in den Kernel gehalten. Der Video4Linux-Code ist komplett neu geschrieben, wobei sich auch einige inkompatible Änderungen ergeben haben - ohne Neukompilierung laufen alte V4L-Anwendungen nicht mehr. Ebenfalls neu im Kernel sind die DVB-Treiber von linuxtv.org, Grundlage unter anderem für den Betrieb von Klaus Schmidingers VDR (Video Disk Recorder, siehe S. 242 in c't 24/2003).

Lokal und remote

Die Zahl der unterstützten Dateisysteme ist weiter angewachsen. Neu im Kernel sind unter anderem das verteilte Andrew Filesystem (AFS), SGIs Journalling Filesystem XFS und ReiserFS4. Der neue NTFS-Treiber gilt als stabiler und schneller, unterstützt mehr NTFS-Features und erlaubt erstmals sichere Schreiboperationen auf NTFS-Partitionen - wenn auch nur beim Überschreiben bereits existierender Dateien ohne Änderung der Dateigröße. Für manche Windows-Systemreparatur von Linux aus mag das aber schon ausreichen. Ebenfalls der Kooperation zwischen den Systemwelten dienlich: Linux 2.6 kann mit den dynamischen Datenträgern von Windows 2000 und XP umgehen. Bei den Netzwerkdateisystemen sind CIFS - die moderne Spielart des SMB-Protokolls der Windows-Dateiserver - und NFS4 hinzugekommen.

Ext2 und ext3 kennen jetzt erweiterte Attribute und Access Control Lists (ACLs) nach POSIX-Standard [4|#literatur]. Der HTree-Patch beschleunigt Verzeichnisoperationen in gut gefüllten Directories, bislang eine Schwäche von ext2/ext3. Der verbesserte Verzeichnisindex lässt sich mit dem Kommando tune2fs -O dir_index auch nachträglich aktivieren.

Dank Linux Security Modules (LSM) lassen sich unterschiedliche Sicherheitsmodelle integrieren. Standardmäßig bringt der Kernel 2.6 lediglich die normalen Linux Capabilities mit; andere Module sind aber vorstellbar und auch schon in Arbeit. Integriert haben die Entwickler das Security Enhanced Linux (SELinux) der NSA [5|#literatur]. Wer damit experimentieren will, sollte unbedingt die Hilfetexte zu den diversen SELinux-Optionen bei der Kernelkonfiguration lesen, wenn er nicht Gefahr laufen will, sich aus dem eigenen System auszusperren.

Wichtigste Neuerung im Bereich Netzwerk ist die Integration von IPSec in den Kernel - nicht das bekannte FreeSWAN, sondern eine neue Implementierung, die sich stark an KAME orientiert. Auf [6|#literatur] finden sich die passenden Verwaltungswerkzeuge. Ob dieser Schritt das Aus für FreeSWAN bedeutet, muss sich zeigen - ein Port der FreeSWAN-Programme auf den neuen IPSec-Code im Kernel existiert jedenfalls schon. Das (ebenfalls neue) Krypto-API liefert die notwendigen Algorithmen zur Authentifizierung und Verschlüsselung. Die IPVS-Patches von linuxvirtualserver.org, die für Load-Balancing in der Transportschicht im Kernel sorgen, sind integriert. NAT hat den Umgang mit einigen problematischen Protokollen wie H.323 gelernt.

Die alten Isdn4Linux-Treiber sind aus dem Kernel verschwunden, stattdessen haben CAPI-Treiber Einzug gehalten. Als Konsequenz unterstützt der Kernel 2.6 nur noch aktive ISDN-Karten von AVM und Eicar.

Innen drin

Schon zu Beginn der 2.5er-Entwicklung wurde Ingo Molnars O(1)-Scheduler integriert. Der alte Linux-Scheduler muss bei jedem Task-Switch die Liste der laufbereiten Prozesse durchsuchen, um zu entscheiden, welcher Prozess an der Reihe ist. Das kostet umso mehr Zeit, je mehr Prozesse auf Ausführung warten: Das System reagiert unter hoher Last immer träger. Der neue Scheduler braucht zum Taskwechsel immer gleich lang, unabhängig von der Anzahl der Prozesse: Der Kernel skaliert besser mit steigender Prozesszahl, interaktive Prozesse reagieren unter hoher Last schneller auf Benutzeraktionen. Auf [7|#literatur] finden sich Werkzeuge, mit denen man die Arbeitsweise des Schedulers beeinflussen kann.

Die Grundidee des O(1)-Schedulers besteht darin, die laufbereiten Tasks - Prozesse oder Threads - in ein Array aus 140 verketteten Listen zu stecken: die Queues 0 bis 99 für Prozesse mit Echtzeitpriorität, die restlichen 40 für die nice-Werte von -20 bis 19. In einer Bitmap zeigen 140 Bits an, welche Listen laufbereite Tasks enthalten. Um herauszufinden, welche Task als nächstes dran ist, muss der Scheduler lediglich das erste gesetzte Bit in der Bitmap finden. Damit niedrig priorisierte Tasks nicht verhungern, arbeitet der Scheduler mit zwei solchen Arrays: Sobald eine Task im "aktiven" Array alle Zeitscheiben aufgebraucht hat, die ihr zustehen, wird sie in ein Array mit abgelaufenen Tasks verschoben. Wenn das Array mit den aktiven Tasks leer ist, tauscht der Scheduler die beiden Arrays aus und beginnt von vorne.

In SMP-Systemen führt der Kernel für jede CPU eine eigene solche Runqueue. Ein Load-Balancer im Scheduler überprüft regelmäßig, ob die Runqueues gleichmäßig mit Prozessen bestückt sind. Sobald die Auslastung der Prozessoren um mehr als 25 Prozent voneinander abweicht, werden Prozesse verlagert, um das Ungleichgewicht zu beseitigen. Dabei unterscheidet der Scheduler zwischen physikalisch verschiedenen Prozessoren und den lediglich logischen CPUs von Hyperthreading-Prozessoren.

Ebenfalls der gefühlten Systemgeschwindigkeit zugute kommt der unterbrechbare Kernelcode (preemptible kernel). Im Kernel 2.4 liegt der Task-Scheduler auf Eis, solange der Prozessor Kernelcode ausführt. Jetzt sind auch Kernelfunktionen an vielen Stellen unterbrechbar, nur noch wenige Codeteile des Kernels sind weiterhin durch Spinlocks geschützt. Das "low latency"-Projekt hat zudem Patches beigesteuert, die längere kritische Codeteile im Kernel aufteilen und mit "preemption points" spicken.

Diese Änderungen vermindern die Latenzen bei Interrupts und Taskwechseln dramatisch (Vergleichsmessungen zwischen Kernel 2.4 und 2.6 haben Faktor 10 und mehr ergeben), sodass Linux schon in den Bereich der weichen Echtzeitanwendungen - Anwendungen, die verlässlich kurze, aber nicht absolut deterministische Reaktionszeiten benötigen - vorstößt. Wichtig ist das im Embedded-Bereich (der "kernel preemption"-Code stammt ursprünglich von MontaVista), aber auch anspruchsvolle Desktop-Anwendungen wie das Dekodierungen von MPEG-Streams in Echtzeit profitieren davon.

Mehr Speicher

Natürlich hat sich im Kernel 2.6 auch wieder eine Menge an der Speicherverwaltung (VM) geändert - seit eh und je Dauerbrenner in den Diskussionen der Kernelentwickler und umstritten auch noch bei den ersten Versionen des Kernels 2.4. Die Entscheidung von Linus Torvalds, mit Linux 2.4.10 die VM im Anwenderkernel auszutauschen, trieb damals die Debatte zunächst auf die Spitze, sorgte dann aber letztlich für (vorübergehende) Ruhe an der VM-Front.

In die 2.6er-VM ist der rmap-Patch von Rik van Riel integriert. Bis zur Version 2.4 verwaltete der Linux-Kernel Speicherseiten in einer Datenstruktur, die es lediglich erlaubt, die physische Speicherseite zu einer logischen Adresse zu finden. Der Kernel 2.6 kann in einer verketteten Liste von Page Table Entries (PTE-Liste) zu jeder physischen Speicherseite nachschlagen, welche Prozesse sie referenzieren. Das beschleunigt die Suche nach nicht mehr verwendeten Speicherseiten, die dann freigegeben und anderen Prozessen zur Verfügung gestellt werden können: Statt alle virtuellen Speicheradressen abzuklappern, kann die rmap-VM die physischen Seitenadressen auf "befreibare" Seiten scannen. Das bringt nicht nur bei Speicherknappheit, sondern auch bei viel physischem Speicher Vorteile.

Eine wichtige Änderung für große Server ist die zu großen Teilen von SGI beigesteuerte NUMA-Unterstützung. Non-Uniform Memory kommt bei Maschinen mit vielen Prozessoren zum Einsatz, um zu verhindern, dass der Zugriff auf den gemeinsamen Speicher zum Engpass wird. NUMA-Architekturen verbinden Einheiten aus einem oder mehreren Prozessoren (Knoten) und zugehörigem Speicher so miteinander, dass die CPUs auch auf "fremden" Speicher zugreifen können - wenn auch langsamer als auf ihr lokales RAM.

Während NUMA-Support im Kernel 2.4 nur rudimentär vorhanden war, kann der neue Linux-Kernel solche Speicherarchitekturen mit ihren speziellen Beziehungen zwischen Knoten, Speicherbereichen und I/O-Geräten adäquat abbilden. Er pflegt beispielsweise für jede Speicherzone eine eigene Tabelle, welche Speicherseiten am längsten nicht genutzt und damit Kandidaten für das Paging auf Platte sind. Auch der Task-Scheduler nimmt auf NUMA Rücksicht und achtet darauf, Prozesse möglichst wenig zwischen Knoten hin- und herzuschieben.

Ebenfalls wichtig für "große" Unternehmensanwendungen ist eine leistungsfähige Thread-Implementierung. Im Kernel 2.6 löst NPTL (benannt nach der Native POSIX Threading Library, die die Thread-Schnittstelle für Anwendungen bereitstellt) die alten LinuxThreads ab, bei denen es vor allem an der Skalierbarkeit haperte. Auf x86-Architekturen lassen sich maximal 8192 LinuxThreads erzeugen, NPTL-Threads haben hier keine feste Obergrenze - über 100 000 Threads sind schon demonstriert worden. Zudem dauert das Erzeugen eines LinuxThreads umso länger, je mehr Threads laufen, während sich ein vollständiger NPTL-Thread mit einem einzigen sys_clone()-Aufruf unabhängig von der Zahl der schon laufenden Threads erzeugen lässt.

Futexe (Fast Userspace Mutexes) machen die Synchronisation von Threads effizienter: Wartet ein Thread darauf, dass sich ein als Lock genutzter Speicherwert ändert, kann er sich über einen einfachen Systemcall so lange schlafen legen, bis sich der Speicher geändert hat. Das erspart regelmäßiges Abfragen oder die bei den LinuxThreads genutzte aufwendige Kommunikation über Signale. Futexe haben sich mittlerweile zu einer über Threads hinaus allgemein nutzbaren Methode zur Synchronisation von Userspace-Prozessen mit Kernelhilfe entwickelt.

Rein und raus

Jens Axboe hat während der Arbeit am Kernel 2.5 die Aufgabe angepackt, das schon lange als renovierungsbedürftig geltende Subsystem für blockorientierten I/O von Grund auf neu zu schreiben. Die damit verbundenen massiven Umstellungen (das alte Block-I/O-System umfasste über eine halbe Million Codezeilen) waren Hauptgrund dafür, dass viele Entwicklerkernel bis etwa 2.5.40 nur bedingt benutzbar waren.

Nach allgemeinem Dafürhalten hat sich die Mühe gelohnt. Lese- und Schreiboperationen auf Massenspeichern sind effizienter und schneller geworden, diverse Limitierungen gefallen: Auf 32-Bit-Architekturen sind Blockdevices bis zu 16 TByte, auf 64-Bit-Architekturen bis zu 8 ExaByte möglich - Luft genug auch für große RAID-Arrays. Der Logical Volume Manager LVM2 ist in den Kernel integriert. ATAPI-Brenner lassen sich jetzt direkt ansprechen, der Hack mit dem IDE-SCSI-Treiber für ATAPI-Geräte ist nicht mehr nötig. Eine Reihe von Aufgaben wie das Tagged Command Queuing, die bislang jeder Gerätetreiber selbst erledigen musste, sind in das Block-I/O-System gewandert. Das macht die Treiberprogrammierung einfacher und weniger fehleranfällig.

Daten, die ein Prozess auf einen Massenspeicher schreibt, nimmt das virtuelle Filesystem (VFS) im Linux-Kernel entgegen und legt sie im Speicher ab. Im Normalfall entscheidet dann letztlich die Speicherverwaltung, welche Speicherseiten wann auf Platte zu schreiben sind. Der im Kernel 2.4 hierfür zuständige bdflush-Prozess (buffer-dirty-flush) ist dem neuen pdflush-Daemon gewichen. Der arbeitet mit mehreren Threads und kann so mehrere Platten gleichzeitig bis zu ihrer maximalen Schreibrate auslasten.

An dieser Stelle kommt das neue I/O-Subsystem ins Spiel. Es arbeitet die zu schreibenden (oder auch gelesenen) Daten nicht mehr in 4-KByte-Blöcken ab, sondern kann beliebig große Datenbrocken an einem Stück zur Hardware schicken - das reduziert die CPU-Last. Ein I/O-Scheduler optimiert dabei den Plattenzugriff und sorgt dafür, dass kein Prozess beim Warten auf I/O verhungert und die Latenzen vor allem beim Lesen gering bleiben.

Da der I/O-Scheduler jetzt als eigenes Modul im Block-I/O-System realisiert ist, stehen im Kernel 2.6 verschiedene I/O-Scheduler zur Verfügung. In den meisten Situationen garantiert der antizipatorische I/O-Scheduler optimale Performance. Lediglich in Umgebungen, in denen seek-Operationen dominieren - etwa bei Datenbanken -, kann der einfachere Deadline-I/O-Scheduler eine 10 bis 20 Prozent höhere Leistung bringen, da er keine Zeit mit dem Versuch verschwendet, die (ja zufällig verteilten) Lese- und Schreiboperationen vorherzusagen.

Nicht nur PCs

Angesichts der zahlreichen unterstützten Hardwarearchitekturen ist die Einführung des Konzepts der Subarchitektur dringend fällig gewesen. Bis zur Version 2.4 galt in Linux die implizite Annahme, dass jeder Prozessorfamilie eine Rechnerarchitektur mit typischen Geräten und Bussen zugeordnet ist. Existierten für einen Prozessortyp mehrere Systemarchitekturen (was nicht nur in der Embedded-Welt vorkommt), konnte die Konfiguration schnell unübersichtlich werden. Der Kernel 2.6 bietet jetzt einfach eine Auswahl der unterstützten Architekturen für die ausgewählte Prozessorfamilie an.

In den neuen Kernel sind große Teile des µClinux-Projektes eingeflossen (www.uclinux.-org). Das Embedded Linux/Microcontroller Project stellt Patches bereit, mit denen Linux auf Microcontrollern ohne MMU läuft. Linux 2.6 unterstützt jetzt von Haus aus die MMU-losen M68k-Prozessoren Dragonball und Coldfire von Motorola, Hitachis H8/300 und den NEC V850E.

Zudem ist das Zeitverhalten vorhersagbarer geworden. Zwar ist auch Linux 2.6 kein hartes Echtzeitsystem, aber der bereits erwähnte O(1)-Scheduler und vor allem die unterbrechbaren Kernelfunktionen sorgen für deutlich kürzere Antwortzeiten. Das Auslagern von Speicherseiten auf Platte lässt sich komplett deaktivieren, um page faults zu unterbinden, deren Behandlung aus Prozessorsicht eine Ewigkeit dauert. Diverse Features wie die verschiedenen I/O-Scheduler lassen sich abschalten, um das Kernel-Image möglichst klein zu halten. Dazu gehört auch, dass man die Unterstützung für grundlegende Ein- und Ausgabegeräte komplett aus dem Kernel entfernen kann - die Kommunikation mit dem Microcontroller in der Waschmaschine dürfte noch auf absehbare Zeit ohne Tastatur und Konsole auskommen.

Konfiguriert ...

Der Kernel 2.6 kommt mit einem neuen Build- und Konfigurationssystem. Die alten Config.in-Dateien sind verschwunden; an ihre Stelle treten Kconfig-Dateien, die die für die Quelltextdateien im jeweiligen Verzeichnis möglichen Optionen samt Typ, Abhängigkeiten und Erläuterung enthalten. Die Datei Documentation/Configure.help mit den gesammelten Hilfetexten ist verschwunden. Eine Konfigurationsoption (entspricht einem Menüpunkt in den diversen Frontends) wird eingeleitet durch das Schlüsselwort "config". Mit "choice" beginnt eine Auswahlliste, mit "menu" ein Untermenü. Die Namen der Optionen in den Kconfig-Dateien entsprechen den Konfigurationsvariablen in .config ohne das vorangestellte CONFIG_.

Bevor man daran geht, den neuen Kernel zu kompilieren, empfiehlt sich wie üblich ein Blick in die Datei Documentation/Changes. Hier erfährt man, welche Software in welchen Versionsnummern nötig ist. Auch nicht mehr ganz brandneue Distributionen wie Red Hat 9 oder SuSE 8.2 genügen im Großen und Ganzen bereits den Ansprüchen - möglicherweise muss man einzelne Werkzeuge aktualisieren, um alle neuen Features nutzen zu können.

Unumgänglich sind hingegen neue Programme für das Modulhandling, sofern die Distribution nicht schon für den Kernel 2.6 vorbereitet ist. Mit der Version 2.5.48 hat der Kernel einen komplett neuen Mechanismus zum Laden von Modulen erhalten. Entsprechend hat sich die Struktur der Module verändert, äußerlich erkennbar an der neuen Namenserweiterung .ko (kernel object). Hauptgrund für den neuen Module Loader waren race conditions, die unter bestimmten Bedingungen beim Entladen eines Moduls auf SMP-Maschinen auftreten konnten. Der Kernel 2.6 ist in dieser Hinsicht nicht nur sicherer, er bietet auch erweiterte Optionen: So lässt sich das erzwungene Entladen von Modulen (rmmod -f) und sogar das Entladen von Modulen überhaupt bei der Kernelkonfiguration abschalten.

Die alten Modutils funktionieren nicht mit dem neuen Module Loader. Dessen Autor Rusty Russell, der sich schon bei dem Wechsel auf Netfilter im Kernel 2.4 einen Namen als Mann fürs Inkompatible gemacht hat (und in dem neuen Module Loader das Entladen von Modulen am liebsten ganz abgeschaltet hätte), stellt neue Module-Init-Tools auf [8|#literatur] zum Download bereit. Debian-Nutzer finden in Sarge vorbereitete Pakete. In den aktuellen Distributionen von SuSE und Red Hat sind die Module-Init-Tools bereits installiert, leicht erkennbar an der Existenz von /sbin/insmod.old, /sbin/modprobe.old und so weiter. Die .old-Versionen kommen automatisch zum Einsatz, wenn ein 2.4er-Modul geladen wird. Wer die Module-Init-Tools aus den Quellen installiert, kann die .old-Dateien mit einem make moveold automatisch erzeugen lassen - Details dazu im README.

Zu den neuen Tools gehört natürlich auch eine neue Konfigurationsdatei namens /etc/modprobe.conf, die die alte modules.conf ersetzt und sich durch das im Paket enthaltene Skript generate_modprobe.conf aus letzterer erzeugen lässt. Etwas Handarbeit dürfte dennoch nötig sein, soll der automatische Modullader nicht gegen die Wand laufen: Diverse Treiber haben neue Namen erhalten; der UHCI-Treiber beispielsweise, der für den USB-Controller vieler Chipsätze zuständig ist, heißt jetzt uhci-hcd (für Host Controller Driver).

Wer unter dem Kernel 2.6 ein modprobe -c aufruft, sieht die praktischen Auswirkungen einer weiteren Neuerung der 2.6er-Module: Es existiert jetzt ein standardisierter Weg, von jedem Modul zu erfahren, für welche Devices es sich zuständig fühlt. depmod nutzt diese Info, um die Datei /lib/modules/2.6.n/modules.alias zu erzeugen, die dabei hilft, bei einem neu angeschlossenen Gerät automatisch den passenden Treiber zu laden.

... und kompiliert

Das Bauen eines neuen Kernels hat sich nicht grundlegend geändert. Eine Grundkonfiguration kann man durchaus mit einem make oldconfig aus der .config-Datei eines 2.4er-Kernels erzeugen; eine anschließende gründliche Durchsicht aller Optionen ist allerdings unumgänglich, wenn der neue Kernel funktionieren soll. Die alte Tk-Oberfläche ist verschwunden, make xconfig startet ein Qt-Programm. Alternativ existiert ein Gtk+-Frontend (make gconfig); die Konsolenklassiker mit und ohne Curses-Menüs sind natürlich erhalten geblieben. Mit der Qt-Oberfläche haben wir gelegentlich merkwürdige Effekte erlebt: Tristate-Optionen wurden dann und wann ohne erkennbaren Grund als nicht anwählbar angezeigt, standen dann in .config aber doch auf "y". Das Gtk+-Interface hingegen stürzte gelegentlich bei Mausklicks ab.

Dank des verbesserten Handlings der Abhängigkeiten zwischen den Optionen und Quelltextmodulen kompiliert der Kernel schneller; vor allem Rebuilds mit veränderter .config sind merkbar beschleunigt, da weniger Code neu kompiliert wird. Ein make dep ist nicht mehr nötig, ein einfaches make erzeugt das komprimierte bzImage, ein unkomprimiertes Kernel-Image (vmlinux) sowie die Module, die sich wie gehabt mit make modules_install installieren lassen. Dabei flimmern nicht mehr sämtliche schmutzigen Details des Build-Prozesses über den Bildschirm, der Anwender erfährt nur noch im Groben, was gerade vor sich geht. Wer es genauer wissen will, nimmt make V=1. make help zeigt alle make-Ziele an.

Der gcc 3.3 eines SuSE-8.2-Systems irritierte beim Übersetzen der Kernelquellen mit einer Unzahl von Warnmeldungen, die sich allerdings durchweg als harmlos erwiesen - bis auf einige Treiber, bei denen im Makefile das Extra-Flag "-Werror" gesetzt ist, das alle Warnungen in Fehler verwandelt und so das Kompilieren beendet. Beherztes Auskommentieren des Flags in den betroffenen Makefiles beseitigt das Problem. Ältere gcc-Versionen verursachten keinen derartigen Ärger. Debian-User müssen nicht einmal den Compiler anwerfen, um in den Genuss des neuen Kernels zu kommen: In Sarge befinden sich recht aktuelle 2.6er-Pakete, die kaum mehr als einen Reboot erfordern. Kaum mehr deshalb, weil wahrscheinlich noch ein wenig Feinarbeit am System nötig ist.

So haben sich sowohl bei den Kernelparametern als auch bei den Optionen einiger Module Änderungen ergeben. Man ist daher gut beraten, nicht blind die Kommandozeile des alten 2.4er-Kernels zu übernehmen, sondern zuvor einen Blick in Documentation/kernel-parameters.txt zu werfen. Auch scheint der Kernel 2.6 mit der Red-Hat-Unsitte, das root-Dateisystem über einen "root=LABEL=/"-Kernelparameter kund zu tun, nicht klarzukommen - hier muss der echte Device-Name stehen.

Je nach Distribution und verwendeter Hardware muss man dem einen oder anderen (Init-)Skript noch auf die Sprünge helfen. Auf Debian-Systemen beispielsweise prüft /sbin/dhclient auf die Kernelversion - von 1.0 bis 2.5. Beim Kernel 2.6 gibt dieses Skript nur ein lapidares "Unrecognized kernel version" aus. Red Hat Linux stolpert darüber, dass /etc/rc.sysinit beim Systemstart die Existenz von /proc/ksyms überprüft - zu dumm, dass die Pseudodatei jetzt /proc/kallsyms heißt. So schaltet das Skript Hotplugging und das automatische Laden von Kernelmodulen ab.

Alle Distributionen sehen einen Mechanismus vor, um grundlegende Module beim Systemstart zu laden. Hier ist meist Handarbeit nötig - eine Suche nach modprobe und insmod in den Init-Skripten hilft, die richtigen Stellen zu finden. Welche Module konkret Ärger bereiten, ist je nach eingesetzter Hard- und Software verschieden.

Einige wenige Anwendungen laufen nicht mit dem neuen Kernel. Davon betroffen ist in erster Linie systemnahe Software: Diverse Monitorprogramme etwa kommen mit den Formatänderungen in einigen Status-Dateien in /proc nicht zurecht. Ein paar Programme haben Probleme mit den POSIX-Threads, was sich häufig in merkwürdigen Fehlfunktionen äußert. Abhilfe ist einfach: Setzt man die Umgebungsvariable LD_ASSUME_KERNEL auf "2.2.5", läuft beispielsweise auch rpm 4 unter Red Hat 9 wieder.

Fazit

Wenige Codeteile im Linux-Kernel sind im Zuge der 2.5er-Entwicklung unverändert geblieben. Dass der Kernel schon jetzt (2.6.0-test9) stabil läuft, spricht für die Qualitäten des Entwicklungsmodells hinter Linux, dem es gelungen ist, Beiträge von hunderten einzelner Entwickler und nahezu allen Größen der IT-Branche - darunter Dell, Fujitsu-Siemens, HP, IBM, Intel, Oracle, SAP und SGI - nahtlos zu integrieren. Linus Torvalds, der die Arbeit am neuen Kernel während der Entwicklung koordinierte, hat ihn bereits an den designierten 2.6-Maintainer Andrew Morton übergeben.

Die meisten Anwender dürften dennoch von den vielen Neuerungen nicht viel spüren, schließlich ist der Kernel 2.4 ja keineswegs katastrophal schlecht. Verbesserungen ergeben sich vor allem in den Extremen: extreme Hardware wie NUMA-Maschinen mit 32 oder mehr Prozessoren, extreme Betriebssituationen wie sehr hohe Last oder Speichermangel, extreme Anforderungen wie Echtzeit. In einem Interview hat Linus Torvalds gesagt, für ihn sei die wichtigste Änderung im Kernel 2.6 das große Aufräumen in den Quelltexten, was die Wartbarkeit des Codes drastisch verbessert hat.

Mit dem neuen Kernel rückt Linux näher an kommerzielle Unix-Versionen wie Solaris heran, erhöht aber auch seine Eignung für Embedded-Anwendungen. Der "durchschnittliche" Linux-User, der das Betriebssystem auf einer Workstation oder einem kleinen Server einsetzt, profitiert von neuen Treibern, einem verbesserten Verhalten in Extremsituationen und einem stabilen, zukunftssicheren Betriebssystem. Dass dabei die Kernelschnittstellen zur Außenwelt nahezu unverändert geblieben sind und nur die allerwenigsten Anwendungen an Linux 2.6 speziell angepasst werden müssen, macht den Umstieg um so einfacher. (odi)