Die Neuerungen von Linux 2.6.24 | heise online

Die Neuerungen von Linux 2.6.24

Sieben neue WLAN-Treiber, eine massiven Umstrukturierung im Quellcode sowie Verbesserungen am CFS-Scheduler und den Stromspartechniken sind die wohl herausragendsten Änderungen der neuen Linux-Version.

vorlesen Druckansicht
Lesezeit: 32 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis
Linux in Zahlen
Linux-
Version
Entwicklungs-
zeitraum
Anzahl
Patches
Diffstat
2.6.1971 Tage66858040 files changed, 515161
insertions(+), 291784 deletions(-)
2.6.2066 Tage47685825 files changed, 262475
insertions(+), 136162 deletions(-)
2.6.2180 Tage50166568 files changed, 319232
insertions(+), 175247 deletions(-)
2.6.2274 Tage65267620 files changed, 519591
insertions(+), 266699 deletions(-)
2.6.2393 Tage66627203 files changed, 406268
insertions(+), 339071 deletions(-)
2.6.24107 Tage983610209 files changed, 776107
insertions(+), 483031 deletions(-)

Mit zirka eineinviertel Millionen neuen, bewegten oder gelöschten Zeilen Quellcode waren die Kernel-Hacker bei Linux 2.6.24 diesmal so emsig wie nie zuvor. Damit markierten sie einen neuen Größenrekord in der Entwicklung der Kernel-Serie 2.6, der wohl einige Zeit Bestand haben dürfte.

Für einen nicht unerheblichen Teil all dieser Änderungen ist die Zusammenlegung der Quellcode-Verzeichnisse für die 32-Bit und 64-Bit-Varianten der x86-Architektur verantwortlich. Doch mit Erweiterungen am noch jungen CFS-Scheduler, der Unterstützung von High Resolution Timers und Dynamic Ticks für nicht-x86-32-Systeme sowie vielen weiteren Anpassungen gab es noch reichlich andere Neuerungen unter der Haube. Und wie immer verbesserte sich durch zahlreiche neue und überarbeitete Treiber die Hardware-Unterstützung mit der neuen Kernel-Version erheblich – so kamen etwa für die in vielen modernen Notebooks und Netzwerk-Produkten verbaute WLAN-Hardware sieben neue WLAN-Treiber hinzu.

Das mehrere Megabyte große Changelog beschreibt all die Änderungen der neuen Kernel-Version im Detail; einen Überblick über die wichtigsten finden Sie auf den folgenden Seiten dieses Artikels:

Ferner bietet der Artikel noch einige allgemeine Informationen zum Linux-Kernel:

[Weiter: Neue WLAN-Treiber und wiederum verbesserter Scheduler.]

Nachdem die Linux-Entwickler bei der Kernel-Version 2.6.22 mit dem WLAN-Stack MAC80211 ein neues Basis-Framework für WLAN-Treiber integrierten, kamen mit 2.6.24 nun endlich auf den noch jungen WLAN-Stack aufsetzende Treiber hinzu. Dabei gingen die Hacker gleich in die vollen und integrierten sieben neue WLAN-Treiber; darunter die im Rahmen des iwlwifi-Projekt entwickelten Treiber iwl3945 und iwl4965, die sich für die beiden in modernen Centrino-Notebooks verwendeten WLAN-Module von Intel eignen. Anders als der von Intel extern gepflegte ipw3945-Treiber arbeiten die beiden Neuen ohne einen proprietären Daemon; der einzige für den Betrieb nötige nicht-offene Code ist die vom WLAN-Modul selbst ausgeführte Firmware.

Neu sind ferner die WLAN-Treiber rt2x00 für verschiedene WLAN-Chips von Ralink, adm8211 für ADMtek ADM8211-Chips und b43 für 802.11g-Chips von Broadcom. Mit p54 für 802.11g-Prism-Chips von Intersil und b43legacy für ältere Broadcom-WLAN-Hardware kamen zudem noch zwei weitere neue Treiber hinzu (wobei der Kernel für die von den beiden unterstützte Hardware mit prism54 und bcm43xx bereits Treiber enhielt, die aber nicht auf den neuen WLAN-Stack aufsetzen, an dem die Entwickler parallel zur Aufnahme der neuen Treiber ein Fülle von Verbesserungen und Korrekturen vornahmen). Parallel wurde auch das zugehörige Konfigurationsinterface CFG80211 um eine Netlink-Schnittstelle erweitert.

Zukünftige Linux-Kernel sollten durch diese Treiber einen Großteil heute gängiger WLAN-Hardware von Haus aus unterstützen – so wie es sich die Entwickler im Mai vorigen Jahres erhofft hatten, als sie den Schwenk auf den neuen WLAN-Stack beschlossen, nachdem sich die Programmierer lange nicht auf ein einheitliches Basis-Framework für WLAN-Treiber einigen konnten. Um die WLAN-Unterstützung rund zu machen, fehlt im Kernel jedoch noch der designierte Madwifi-Nachfolger ath5k. Einige Distributionen liefern ath5k aber bereits aus – ähnlich, wie Fedora 7 und 8, Ubuntu 7.04 und 7.10 sowie OpenSuse 10.3 bereits seit Monaten die jetzt in den offiziellen Linux-Kernel aufgenommenen WLAN-Treiber enthalten. Die Distributionen liefern auch die von vielen WLAN-Treibern benötigten Firmware-Dateien mit und konfigurieren die Hardware automatisch.

Der mit 2.6.23 integrierte und für die Zuteilung von CPU-Zeit an die Anwendungen zuständige Completely Fair Scheduler (CFS) erfuhr für 2.6.24 zahlreicher Änderungen und soll so noch exakter und flotter als zuvor arbeiten. Zudem lassen sich nun Gruppen definieren, zwischen denen der Scheduler die CPU-Zeit fair verteilt (Fair Group Scheduling).

In der Standard-Konfiguration teilt CFS die CPU-Zeit pro Anwender ein – wenn drei Nutzer an einem System jeweils ein oder mehrere prozessorlastige Programme ausführen stellt CFS sicher, dass jeder Anwender ein Drittel der CPU-Zeit erhält, die CFS dann wieder unter dessen Prozessen aufteilt. Über Task Control Groups (siehe auch basic task cgroup framework, 1, 2, 3) lassen sich aber auch beliebige Gruppen festlegen, damit Admins und deren Freunden genug Rechenzyklen für Spiele wichtige Aufgaben zur Verfügung stehen.

Der Hauptentwickler von CFS hatte ursprünglich angenommen, das die Arbeit am Scheduler mit 2.6.24 im großen und ganzen abgeschlossen würde – in den vergangenen Wochen haben aber verschiedene Entwickler CFS noch weiter optimiert und zahlreiche Patches für die nächste Kernel-Version eingesandt. So wird auch 2.6.25 wohl weitere Verbesserungen am Prozess-Scheduler mitbringen.

Mit 2.6.24 integrierten die Entwickler auch die Unterstützung für High Resolution Timer auf den x86-64-, PPC- und MIPS-Architekturen – für x86-32-Systeme war diese mit Linux 2.6.21 hinzugestoßen. Zusammen mit Hardware, die HPET (High Precision Event Timers) oder andere genaue Zeitgebertechniken beherrscht, kann der Kernel dadurch viel genauer als bisher zu einem vorher festgelegten Zeitpunkt eingreifen, um eine bestimmte, vorher festgelegte Aufgabe zu erledigen. Das ist unter anderem für Echtzeit-Anwendungen wichtig, bietet aber auch für andere zeitkritische Software Vorteile – etwa bei der Audio-Bearbeitung.

Genau wie die High Resolution Timer für 32-Bit-Systeme in 2.6.21 bringen die Varianten für die anderen Architekturen Huckepack die Dynamic Ticks (Tickless Idle) mit. Der Kernel kann durch diese Erweiterungen auf modernen Systemen den Timer-Interrupt auf den Zeitpunkt der nächsten absehbaren Aufgabe programmieren. So kann der Prozessor bei einem ansonsten untätigen System in Ruhe bis zum nächsten Einsatz ausspannen und bis zur nächsten Aufgabe oder dem Auftreten eines IRQs in den Stromsparmodus wechseln. Das soll die Leistungsaufnahme reduzieren und so die Batterielaufzeit bei Notebooks verlängern, denn bisher musste die CPU zur Abarbeitung des stetig tickenden Timer-IRQs je nach Kernel-Konfiguration hundert bis tausend Mal pro Sekunde unnütz aufwachen. Damit sich die Leistungsaufnahme aber auch tatsächlich reduziert, dürfen auch die Anwendungen den Prozessor nicht unnötig aufwecken – das ist nur bei sehr neuen Distributionen der Fall, die daraufhin optimiert wurden. Das Programm Powertop hilft bei der Suche nach Anwendungen, die den Prozessor unnötig im Schlaf stören.

Auch viele x86-Notebooks mit einer 32-Bit-Distribution dürften mit Linux 2.6.24 einen längere Akkulaufzeit aufweisen, denn dank Cpuidle nutzt der neue Kernel die Stromsparmechanismen moderner x86-Prozessoren effizienter. Gerade auf neueren (Centrino-)Notebooks sollte sich die Unterstützung von Stromspartechniken im HD-Audio-Soundtreiber auswirken, die bei einigen Notebooks die Leistungsaufnahme um ein halbes Watt senken soll. Auch das neu integrierte SATA-Link-Power-Management im ahci-Treiber dürfte vornehmlich bei neueren Geräten Vorteile zeigen – laut den Entwicklern liegt das Sparpotenzial bei bis zu einem Watt pro SATA-Anschluss. Mit aggressiven ATA-Stromspareinstellungen geht allerdings ein Geschwindigkeitsverlust einher.

Für Container-/Control-Groups-Virtualisierungslösungen wie OpenVZ oder Linux-VServer gab es verschiedene Neuerungen mit 2.6.24; etwa die Abstraktion des /proc/net-Verzeichnisses, separate Namespaces für Prozesse einer Control Group, Unterstützung im Prozess-Scheduler, der virtuelle Netzwerktreiber veth und Support für schreibgeschützte Bind-Mounts. [Update] Dabei handelt es sich aber nur um erste Teile der nötigen Infrastruktur für "r/o bind mounts" – weitere sollen später folgen. [/Update].

Die im Kernel enthaltene Virtualisierungslösung KVM emuliert nun selbst die verschiedenen Arten (PIC, Local APIC, I/O APIC) der in modernen Systemen zu findenden Interrupt-Controller. Das soll Performance und Kompatibilität verbessern, was auch für Emulation der die HTL-Instruktion gilt. Auch x64-Windows soll dank einer Änderung nun unter KVM laufen.

Über die neu aufgenommenen Virtio-Schnittelle sollen Gast- und Host-Systeme in Zukunft zügig Daten austauschen. Die Entwickler hoffen, das verschieden Virtualisierungstechniken in Zukunft ihre Storage- oder Netzwerk-Controller Virtio-kompatibel emulieren – ein etwa mit Lguest installiertes Gastsystem sollte so dank der generischer Virtio-Treiber beispielsweise auch unter KVM booten.

Mit 2.6.24 legten die Linux-Entwickler den bisher in separaten Verzeichnissen verwalteten Quellcode für die beiden x86-Architekturen im Verzeichnis arch/x86/ zusammen (siehe etwa diesen Commit). Bisher hatten die beiden Architekturen jeweils eigene Verzeichnisse, obwohl nicht unerhebliche Teile der Codebasis der unter den Kürzeln x86, x86-32, i386, ix86 oder IA32 bekannten 32-Bit-x86-Architektur und der als x86-64, x86_64, x64, AMD64T, EM64T oder IA32e geläufigen 64-Bit-Befehlssatzerweiterung ähnlich oder identisch sind. Das führte in der Vergangenheit gelegentlich dazu, dass eine Korrektur etwa nur in den x86-32-Code unter arch/i386/ Einzug hielt, aber für arch/x86_64/ vergessen wurde – oder umgekehrt.

Bei beiden Architekturen identische Dateien legten die für die Vereinigung zur Hilfe genommenen und eigens programmierten Skripte einfach zusammen; nur für x86-32-Systeme interessanter Code wurde in Dateien mit _32-Anhängsel verschoben, während die Dateinamen mit 64-Bit-spezifischen Code ein _64 enthalten. Durch Include- und Makefile-Tricks soll so etwa für alte x86-32-Systeme benötigter Code nicht in x86-64-Kerneln compiliert werden. In den kommenden Wochen und Monaten wollen die Entwickler dann die Feinarbeit erledigen und die _32- und _64-Dateien weiter aufräumen und, wo es sinnvoll ist, zusammenlegen.

Durch diese massive Umstrukturieren erhoffen sich die Entwickler einfacher wartbaren Quellcode und so langfristig einen zuverlässigeren Kernel mit weniger Fehlern. Durch die Zusammenlegung verringert sich bei der Entwicklung neuer Techniken für x86-Systeme auch der Portierungsaufwand erheblich. Für den Anwender ergeben sich, von diesen indirekten Vorteilen abgesehen, keine nennenswerten Auswirkungen; wer Kernel selbst kompiliert, muss jedoch die Konfiguration anpassen und dort jetzt auswählen, ob er einen 32- oder 64-Bit-Kernel wünscht. Auch Skripte, die etwa den kompilierten Kernel unter arch/{i386,x86_64}/boot/bzImage erwarten, wollen auf die neuen Gegebenheiten abgestimmt werden.

Der Plan zur Vereinigung wurde im vergangenen Juli das erste Mal diskutiert – zahlreiche Entwickler waren von der Idee von Anfang an sehr angetan. Einzelne Hacker sprachen sich aber auch dagegen aus – darunter auch Andi Kleen, der bisherige Verwalter für den Code der x86-32- und x86-64-Architekturen. Torvalds und andere führende Entwickler setzten die Zusammenlegung allerdings durch – in Folge dessen trat der Verwalter für die x86-Architekturen zurück. Diese Aufgabe teilen sich in Zukunft Thomas Gleixner, Ingo Molnar und H. Peter Anvin.

Während die Zusammenlegung der x86-32- und x86-64-Verzeichnisse nur wenige Bug-Reports während der 2.6.24-Entwicklung nach sich zog, hatten die Kernel-Hacker bei einer Umstrukturierung des Treiber-APIs für DMA-I/O-Operationen ein weniger glückliches Händchen: Auf einigen Architekturen und mit verschiedenen Treibern zeigte sich Fehlverhalten. Das korrigierten die Entwickler zwar zügig, doch auch einige der unabhängig vom Kernel gepflegten Treiber dürften Anpassungen benötigen – mit deren Umsetzung starten die Treiberbetreuer meist erst, nachdem die Kernel-Entwickler eine neue Linux-Versionen offiziell freigeben.

Nach langer Entwicklungszeit wurden in 2.6.24 nun endlich eine Reihe als "Anti-fragmentation" bezeichnete Patches aufgenommen, die die Fragmentierung im Arbeitsspeicher eindämmen sollen – nach einigen Tagen intensiver Benutzung hatten Kernel bislang kaum mehr größere zusammenhängende Speicherbereiche zur Verfügung.

Entfernt wurde die Möglichkeit, LSMs (Linux Security Modules) zu entladen; mit dem selben Patch wurde auch das externe API für auf LSM aufsetzenden Code entfernt. Die beiden Änderungen sind nicht unumstritten und haben eine lange Diskussion nach sich gezogen.

Beim Aufwachen aus dem Ruhezustand (Suspend-to-Disk/Hibernate) kann auf x86-64-Systemen nun ein beliebiger Kernel das vorher erzeugte Speicherabbild wieder in den Speicher laden und ausführen.

Ein Update für das Ext4-Dateisystem korrigiert einige Fehler und bringt zwei neue Features: Das erstellen und Prüfen von Dateisystemen sollen "Uninitialized Block Groups" beschleunigen, während "Flexible Block Groups" die Verarbeitung von großen Dateien auf Dateisystemen mit kleinen Blockgrößen auf Trapp bringt. Ext4 behält derweil weiter seinen experimentellen Status.

Neben all diesen Änderungen gibt es zahlreiche weitere mit je nach Einsatzgebiet mehr oder weniger Bedeutung für den Linux-Einsatz, die am Ende des Artikels mit einer Kurzbeschreibung auflistet werden.

Wie üblich bringt die neue Kernel-Version zahlreiche neue und überarbeitete Treiber mit und enthält Anpassungen der sie umgebenden Subsysteme. So wurde das USB-Subsystem etwa um Mechanismen zur Geräte-Authentifizierung erweitert – dabei handelt es sich um erste Teile zur Linux-Unterstützung von Wireless USB, wo ähnlich wie bei Bluetooth Authentifizierungs-Mechanismen von Nöten sind, um groben oder lustigen Unfug sowie Angriffe zu verhindern.

Das Libata-Subsystem beherrscht mit 2.6.24 über ACPI kontrolliertes Hotplug – das sollte bei mehr Notebooks als zuvor im laufenden Betrieb den Austausch des integrierten DVD-Laufwerks gegen einen Zusatz-Akku ermöglichen. Die ATA-Treiber ahci und sata_sil für AHCI- und Silicon-Image-Controller sprechen dank Port-Multiplier-Unterstützung ab 2.6.24 nun auch externe SATA-Gehäuse an, die über ein Kabel angebunden werden und mehrere Festplatten enthalten. Entfernt wurde ein Erkennungsmechanismus für Datenfehler beim Einsatz von NCQ (Native Command Queuing) – der Code arbeitete nicht korrekt und sorgte für allerlei Fehlalarme beim Zusammenspiel mit Festplatten.

Die ACPI-Unterstützung in libata ist nun standardmäßig eingeschaltet (Zitat aus dem Commit: "Let's see what explodes"), was nun auch bei neueren Notebooks den Einsatz der System-Schlafzustände ermöglichen sollte, wenn ein Festplatten-Passwort gesetzt ist. Die Kernel-Entwickler lassen den sata-mv-Treiber bei einigen Highpoint RocketRAID-Controller eine Warnung (1, 2) aufgeben, da dieser Controller in bestimmten Modi im vorderen, normalerweise ungenutzten Bereich der Festplatte schreibt und dadurch eine Grub-Installation stört; zudem sollen die Controller wohl auch am Ende der Festplatte in gewissen Fällen Daten überschreiben.

Das Audio-Subsystem entspricht jetzt in ungefähr dem Stand der Alsa-Version 1.0.15; die Unterstützung für die verschiedenen HDA-HDA-Codecs lässt sich in der Konfiguration nun separat auswählen. Zudem gab es wie jedes mal für verschiedene PCs, Mainboards und Notebooks eine ganze Reihe neuer Geräte-spezifischer Sonderbehandlungen. Den alten OSS-Audio-Treiber es1371 entfernten die Entwickler derweil, da ein gleichwertiger Alsa-Treiber bereitsteht.

Neue Treiber gab es wie üblich zahlreich; für Fujitsu-Notebook enthält der Kernel etwa nun den Treiber fujitsu-laptop, der unter anderem die Hintergrundbeleuchtung reguliert. Erstmals enthalten ist auch ixgbe für 10-Gigabit-Ethernet-Chips von Intel oder und sata_fsl für Freescale-SATA-Controller. Auch e1000e, eine stark überarbeitete Variante des e1000-Treibers für Intel-Netzwerkhardware, gehört mit 2.6.24 nun zum Kernel; der neue Treiber kommt vorerst nur für die in neueren Intel-Southbriges enthaltene Netzwerk-Logik sowie einige ausgewählte Netzwerk-Chips zum Einsatz.

Erstmals in 2.6.24 enthalten ist auch ein generisches Framework (1, 2, 3) für Secure Digital Input Output (SDIO) – kleine Geräte wie GPS-Empfänger, Modems, Netzwerkadapter oder Digitalkameras verbinden sich über dies Interface und den auch für SD-Cards geeigneten Slots mit dem System. Unter anderem setzt ein Treiber für UART/GPS Geräte sowie einer für MMC-over-SPI bereits auf das neue Framework auf.

Neu sind auch die V4L/DVB-Treiber ivtvfb (IVTV-Framebuffer) oder TCM825x. Zudem wurden verschiedene V4L/DVB-Treiber überarbeitet; etwa um Dual-DVB-T-Sticks wie Pinnacle Dual DVB-T, Terratec Cinergy DT USB XS diversity und Hauppauge Nova TD USB zu unterstützen.

Unter den zahlreichen in Linux 2.6.24 integrierten Patches sind viele weitere, die die Hardware-Unterstützung verbessern, den Funktionsumfang der zahlreichen Treiber erweitern oder in ihnen enthaltene Fehler korrigieren; die wichtigsten der bisher nicht genannten Änderungen finden mit einer Kurzbeschreibung am Ende des Artikels Erwähnung.

Nach der Freigabe von Kernel 2.6.24 beginnt nun die heiße erste Entwicklungsphase von 2.6.25. In der dürften die Kernel-Hacker die teilweise durch Skripte automatisch durchgeführte Zusammenlegung des x86-Quellcodes weiter vorantreiben und in Handarbeit viele der 32-Bit- und 64-Bit-spezifischen Quellcodedateien zusammenführen. Zahlreiche Patches, die dies erledigen, liegen schon vorbereitet vor. Den Vereinigungsprozess wird 2.6.25 allerdings sicher noch nicht abschließen – vielmehr wird die Arbeit vermutlich nach und nach über die nächsten Monate und Jahre erledigt.

Für 2.6.25 liegen auch zahlreiche Patches für die ptrace-Infrastruktur bereit – darunter einige vorbereitende Patches für den Schwenk auf das Debug- und Tracing-Framework utrace. Dessen Programmierer hofft schon seit längerem auf die Integration von utrace in den Kernel, doch ob das mit 2.6.25 jetzt endlich klappt, steht noch in den Sternen und scheint derzeit eher unwahrscheinlich.

Mit SMACK (Simplified Mandatory Access Control Kernel for Linux) könnte nach SELinux ein zweites Sichereheitsframework in den Kernel einziehen. An KVM und der Unterstützung für Container-Virtualisierung dürfte es wie bei den vorherigen Kernel-Versionen auch größere Erweiterungen geben; den bei 2.6.23 zum Kernel gestoßenen Xen-DomU-Code für x86-32-Gäste wollen einige Entwickler um Unterstützung für die x86-64-Architektur erweitern.

Die im Artikel bislang erwähnten Neuerungen der jüngsten Linux-Version stellen nur eine Auswahl der bedeutsamsten Änderungen dar – die sprichwörtliche Spitze des Eisbergs, der bei jeder neuen Linux-Version im Hauptentwicklungszweig aus Tausenden von Patches besteht. Zahlreiche weitere mehr oder weniger signifikante Neuerungen finden sich im folgenden mit einer Kurzbeschreibung. Letztere verlinkten auf die jeweiligen Changesets des von Linus Torvalds mit Git verwalteten Quellcodes in einem Git-Depots auf kernel.org. Über die Links finden sich viele weitere Informationen; auch die Patches selbst sind dort abrufbar und selbst ohne Programmierkenntnisse eine gute Informationsquelle, da sie meist Kommentare und manchmal auch Dokumentationsänderungen enthalten.

Architektur-Code:

VFS und Dateisysteme:

ACPI:

Input:

PCI/USB-Subsystem:

IDE-Subsystem (alte Parallel-ATA-Treiber sowie einzelne für Serial-ATA-Controller):

libata (Parallel- und Seriell-ATA):

SCSI:

Netzwerk:

Audio:

Grafik:

V4l/DVB:

Hardware-Monitoring:

Verschiedenes:

Eine ähnliche Zusammenfassung der Änderungen von 2.6.24 pflegen die Kernelnewbies in ihrem Wiki. Sämtliche Änderungen der neuen Linux-Version listet das detaillierte Changelog oder das Git-Webinterface. In letzterem lässt sich durch den kompletten Verzeichnis-Struktur des Linux-Kernels navigieren sowie Quellcode und dessen Entwicklungshistorie anzeigen. So kann man etwa verfolgen, was sich an einzelnen Treibern oder Bereichen des Kernels in letzter Zeit verändert hat, etwa beim ahci-Treiber, beim ext4-Dateisystem, der Dokumentation der Kernel-Parameter oder der Liste der zu entfernenden Features. (thl]/c't)

Im folgenden einige im Artikel bereits verlinkte Hintergrund-Informationen zum Linux-Kernel und dessen Entwicklung:

Linux-Kernel stehen über die Server der Domain Kernel.org zum Download bereit; die Version 2.6.24 etwa als Bzip2 komprimierter Patch gegen 2.6.23 oder als komplettes Archiv über die die in Europa aufgestellten Server des Kernel.org-Verbunds. Schon bald nach der Veröffentlichung neuen Linux-Versionen sind sie auch über die deutschen Spiegelserver als Patch oder das komplette Archiv erhältlich. Die Server werden dynamisch zugewiesen; es kommt daher gerade kurz nach der Freigabe neuer Dateien gelegentlich vor, dass man auf einem Spiegelserver landet, der die neuen Dateien noch nicht vorhält.

Wenn es keinen triftigen Grund für den Umstieg auf eine neue Kernel-Version gibt, sollte man die Kernel-Pflege dem Linux-Distributor überlassen, denn einen Kernel selbst zu konfigurieren, kompilieren und installieren, erfordert fortgeschrittene Linux-Kenntnisse und ist zeit- und arbeitsintensiv – letzteres insbesondere auch durch die später benötigte Pflege, denn die Kernel-Entwickler geben pro Monat meist mehrere überarbeitete Versionen heraus. Einige von ihnen stopfen Sicherheitslücken, sodass man die ganze Installationsprozedur erneut durchlaufen muss.

Zudem enthalten die Kernel der Distributionen gelegentlich Patches oder zusätzliche Treiber, die dem offizielle Kernel fehlen. Wer für seine Hardware solche Treiber benötigt, muss diese im Internet suchen, herunterladen, kompilieren und installieren, was die Installation eines eigenen Kernels weiter verkompliziert und verlängert. Auch die zusätzlichen Patches im Distributions-Kernel sind teilweise von Wichtigkeit. So manche die Distribution läuft daher mit einem selbst kompilierten Kernel nicht so rund wie gewohnt oder es fehlen gewisse Funktionen.

Die Entwicklerzweige der jeweils nächsten Distributionsversionen von Fedora, OpenSuse oder Ubuntu enthalten häufig aktuelle Kernel-Versionen und sind daher häufig die beste Basis, wenn man einen neuen Kernel braucht. Will man nicht gleich auf eine solche Entwicklerversion wechseln, um die Vorteile eines neuen Linux-Kernels zu genießen, können fortgeschrittenen Linux-Anwender diese häufig mit vertretbarem Aufwand auch in den aktuellen Versionen der jeweiligen Distribution einbinden. Bei Fedora kann man aber auch schlicht ein bisschen warten, denn das Projekt liefert traditionell neue Kernel-Version einige Tage oder Wochen nach deren Erscheinen als reguläres Update für die die aktuellen Versionen der Distribution aus.

Die Kernel-Hacker entwickeln den Linux-Kernel im Rahmen der 2.6-Serie stetig weiter. Dabei scheuen sie auch nicht vor umfangreichen Änderungen zurück – einen 2.7-Entwicklerzweig, aus dem irgendwann ein Linux 2.8.0 oder 3.0.0 hervorgeht, wie Linux 2.6.0 aus dem 2.5-Entwicklerzweig entstand, wird es daher auf absehbare Zeit nicht geben.

Die Hauptentwicklungslinie stellen die Versionen mit drei durch Punkte getrennten Nummern (2.6.x, also etwa 2.6.24) dar, über die Linus Torvalds selbst wacht. Bei vielen Entscheidungen greift er aber auf die Hilfe zahlreicher anderer Kernel-Hacker zurück. Parallel zur Hauptentwicklung pflegen die Verwalter der Stable-Kernel-Serie die beiden jeweils neusten Versionen der 2.6-Serie weiter und kennzeichnen die Überarbeitungen durch eine zusätzliche Zahl (2.6.x.y, beispielsweise 2.6.22.10 oder 2.6.23.8). Um nicht mit der Hauptentwicklungslinie zu konkurrieren und möglichst nur Fehler zu korrigieren, statt neue auszulösen, haben sich die Stable-Kernel-Betreuer selbst strenge Regeln auferlegt; so dürften die Patches nicht länger als hundert Zeilen sein, müssen einen kritischen Fehler korrigieren und sollten auch in den von Torvalds gewarteten Kernel bereits aufgenommen worden sein.

Die aktuellen Linux-Versionen werden zirka fünf Monate (zwei Entwicklungszyklen) gewartet, bevor man auf einen neue 2.6.x-Version umsteigen solle, weil die Stable-Kernel-Verwalter dann selbst bei Sicherheitslücken keine neue Varianten der alten Linux-Kernel herausgeben. So ein Umstieg ist allerdings nicht ohne Risiko, da sich mit jedem Entwicklungszyklus der ein oder andere neue Fehler einschleicht. Viele Linux-Distributoren pflegen ihre Kernel daher länger, statt neue Versionen auszuliefern – bei den Enterprise-, Server- und Workstation-Distributionen von Debian, Novell und Red Hat erhält man sogar über mehrere Jahre lang Sicherheitsupdates für die enthaltenen Kernel. Die enthalten allenfalls einige neue und überarbeitete Treiber sowie einige wenige, ausgewählte Neuerungen aus jüngeren Linux-Versionen; die Distributoren erhoffen sich davon ein besseres Zusammenspiel mit (neuer) Hardware, ohne dass die Anwender sich mit Fehlern herumschlagen müssen, die neue Kernel-Versionen vielleicht einschleppen.

Adrian Bunk pflegt in Eigeninitiative noch die Kernel der 2.6.16-Reihe nach den Stable-Kernel-Rules weiter – er spart dabei neue Treiber aber weitgehend aus, sodass den 2.6.16.y-Kerneln auf neuen Desktop-PCs häufig Treiber fehlen. Noch weniger Treiber für moderne Hardware enthalten die ebenfalls noch gepflegten Kerneln der 2.4-Reihe; für Server mit bereits installiertem Linux sind diese Kernel-Serien allerdings für von Interesse, da die Gefahr neuer Fehler bei so konservativ gewarteten Kernel-Serien recht gering ist.

Direkt nach der Freigabe einer neuen Kernel-Version beginnt die zirka zwei Wochen lange erste Phase des Entwicklungszyklus, in der die Kernel-Hacker umfangreichere Änderungen in den von Torvalds verwalteten Entwicklerzweig aufnehmen, aus dem die nächste Kernel-Version hervorgeht. In der darauf folgenden, meist zirka sieben bis zehn Wochen langen zweiten Entwicklerphase integriert der Linux-Vater dann im wesentlichen nur noch Fehlerkorrekturen oder kleinere Änderungen, bevor er nach zirka zweieinhalb bis drei Monaten wieder eine neue Kernel-Version veröffentlicht. Das soll die Kernel-Hacker dazu bringen, sich in der zweiten Entwicklungsabschnitt verstärkt auf die Korrektur von Fehlern zu konzentrieren, und verhindern, dass komplexere Änderungen neue Fehler nach sich ziehen.

Viele der im ersten Entwicklungsabschnitt integrierten Änderungen in Form von mit Diff erzeugten Patches bereiten die Kernel-Hacker vor. Zumeist erst im stillen Kämmerlein der Entwickler, bevor diese die Patches auf einer Subsystem-spezifischen Mailingliste und anschließend auf der Linux Kernel Mailing List (LMKL) zur Diskussion stellen. Findet der Patch einigermaßen Anklang, wandert er normalerweise zu Testzwecken in den von Andrew Morton gepflegten mm-Entwicklerkernel. Sehen die für den jeweiligen Kernel-Bereich zuständigen Kern-Entwickler rund um Torvalds den Patch als ausgereift an, wandert er schließlich zu Beginn des nächsten Entiwcklungszyklus in den offiziellen Kernel.

Durch diese öffentliche Entwicklung und einen tiefen Blick in den Kaffeesatz sind der Autor dieses Artikels und der von der Linux-Foundation gewartete Radarschirm des Linux Weather Forecast bereits bei der Vorstellung einer neuen Kernel-Version grob in der Lage abzuschätzen, welche größeren Neuerungen die darauf folgende Version enthalten dürfte. Welche Patches allerdings tatsächlich in die nächste Kernel-Version einziehen, lässt sich dennoch nicht sicher vorhersagen. Schon häufig ist es vorgenommen, das Torvalds oder andere wichtiger Linux-Entwickler Neuerungen, denen verschiedene Beobachter und langjährige Linux-Hacker gute Chancen auf einen Einzug in die nächste Kernel-Version gegeben hatten, nachhaltig kritisierten. In Folge dessen wurden die Änderungen dann erstmal ausgespart; sie finden dann häufig nach weiteren Diskussionen und Anpassungen ein oder zwei Versionen später den Weg in den offiziellen Linux-Kernel. Ab und an verschwanden aber selbst größere Neuerungen mit guten Chancen auf die Integration nach Kritik wieder komplett von der Bildfläche und gerieten in Vergessenheit. Gelegentlich aber geht es in der ersten Entwicklungsphase des Linux-Zyklus auch ganz schnell und die Entwickler integrieren erst kurz zuvor veröffentlichte Patches nach nur wenigen Tagen direkt in den offiziellen Kernel. (thl)