Die wichtigsten Neuerungen von Linux 2.6.20

Inhaltsverzeichnis

Nach mehreren Vorabversionen und einer Entwicklungszeit, die länger dauerte als ursprünglich geplant, hat Linus Torvalds den Linux-Kernel 2.6.20 freigegeben. Mit den Virtualisierungstechniken KVM (Kernel-based Virtual Machine for Linux) und paravirt_ops kamen zwei größere neue Funktionen hinzu; auch zahlreiche Treiber sind erstmals enthalten oder wurden überarbeitet. Größere Änderungen an der bestehen Infrastruktur gab es anderes als bei den vorherigen Versionen diesmal kaum. Linus Torvalds hatte das Entwicklungstempo vorübergehend bewusst gedrosselt, und hoffte so bei 2.6.20 auf eine ruhigere und nicht so lange Entwicklungsphase – das brachte er unter Anderem in den Mails zur Freigabe der ersten und siebten Vorabversion zum Ausdruck. Hintergrund für diese im Vergleich zu den Vorversionen vorsichtigere Herangehensweise dürften diverse während der 2.6.19-Entwicklung geführte Diskussionen sein. In ihnen hatten einige Teilnehmer unter anderem gefordert, bei der Linux-Entwicklung ab und an für eine Version auf neue Features zu verzichten und sich ausschließlich auf Fehlerkorrekturen zu konzentrieren.

Ganz so vorsichtig war der Ansatz bei 2.6.20 dann aber doch nicht. So belegt der Patch extrahiert mit knapp 19 MByte zwar nur etwas mehr als halb so viel Platz wie der Ende November vorgestellten Version 2.6.19, enthält aber trotzdem reichlich Neuerungen.

Virtualisierung

Während Xen schon lange vergeblich auf die Integration in den offiziellen Kernel hofft, schafften das mit 2.6.20 nun zwei andere Virtualisierungstechniken. Eine davon ist eine paravirt_ops genannte generische Schnittstelle. Sie ermöglicht dem Kernel als Gast die Zusammenarbeit mit den Hypervisoren verschiedener Virtualisierungslösungen. Ein mit dieser Erweiterung kompilierter Kernel soll sowohl auf einem Standard-PC als auch unter verschiedenen Virtualisierungslösungen wie Xen oder dem Virtual Machine Interface (VMI) von VMware jeweils mit hoher Geschwindigkeit arbeiten. Anfangs nutzte nur der experimentelle, im Rahmen der paravirt_ops-Entwicklung programmierte Minimal-Hypervisor lguest (vormals: lhype) die neue Schnittstelle. Die Xen-Entwickler präsentierten im Januar ebenfalls Anpassungen an paravirt_ops – das dürfte die Chancen erhöhen, Teile von Xen in den Kernel zu integrieren. Für den Betrieb mit VMI sind derzeit noch weitere Kernel-Patches erforderlich und auch die x64-Architektur unterstützt die neue Schnittstelle noch nicht.

Bei KVM arbeitet der Kernel nach Laden eines Moduls selbst als Hypervisor für virtuelle Linux- oder Windows-Maschinen. Das gelingt jedoch nur in Zusammenarbeit mit den Virtualisierungsfunktionen aktueller x64-Prozessoren von Intel (VT: Vanderpool) oder AMD (AMD-V: Pacifica/Presidio, Secure Virtual Machine/SVM). KVM war erst im Oktober 2006 der Öffentlichkeit präsentiert worden und läuft auch unter älteren Kerneln. Wie bei Xen nutzt auch KVM zur unterstützenden Emulation typischer PC-Komponenten ein modifiziertes Qemu, um etwa eine Netzwerkkarte in den virtuellen Maschinen bereitzustellen. Nach der Aufnahme von KVM zu Beginn der Entwicklung von 2.6.20 wurde die Umgebung noch laufend verbessert; einige Erweiterungen stehen bereits für 2.6.21 in Wartestellung, darunter ein überarbeitetes Interface zwischen Kernel und Userland. Zudem existiert bereits ein experimenteller Ansatz, mit dem ein in Teilen para-virtualisierter Linux-Gast unter KVM besserere Performance bieten soll.

Infrastruktur

Trotz der vorsichtigeren Herangehensweise bei 2.6.20 gab es doch einige Änderungen und Erweiterungen an der Infrastruktur von Linux. Größere Anpassungen in zahlreichen Bereichen des Kernel-Quellcodes erfolgten etwa im Rahmen einer Überarbeitung des Workqueue-Mechanismus und dessen APIs. Er regelt die Ausführungszeitpunkt bestimmte Kernel-Aufgaben und soll das nun mit weniger Overhead als zuvor erledigen.

Kernel 2.6.20 lässt sich mit einer internen Timerfrequenz von 300 Hertz konfigurieren – bisher waren 100, 250 und 1000 Hertz möglich. Linux soll so sowohl bei der Video-Wiedergabe von PAL (25 fps) als auch von NTSC (knapp 30 fps) ein besseres Reaktionsverhalten zeigen, da sich 300 sowohl durch 30 als auch 25 teilen lässt.

Das Kernel-Image ist auf der x86-Architektur nun relocatable, muss also nicht mehr wie zuvor an einerm bestimmten Speicherbereich vorliegen. Der kompilierte Kernel wird durch die Erweiterung zirka 10 Prozent größer, zur Laufzeit soll es jedoch keinen Unterschied im Speicherverbrauch geben. Durch diese Erweiterung müssen die Distributoren nun nicht mehr separate Kernel-Images für kexec oder kdump ausliefern. Diese beiden Techniken arbeiten seit 2.6.20 nun auch auf IA64.

An dem in 2.6.19 aufgenommenen Cluster-Dateisystem GFS2 gab es zahlreiche Korrekturen und Erweiterungen. Relative atime verändert das Verhalten beim Aktualisieren des Access-Zeitstempels in Dateisystemen; das gelingt bisher nur mit OCFS2 und ist etwa für Mail-Clients wie mutt interessant. Mittels IO-Accounting lassen sich zukünftig die Menge der Ein- und Ausgaben von Prozessen genauer analysieren. Über das Fault Injection Framework können Entwickler Fehler etwa bei der Speicheranforderung gezielt oder zufällig simulieren, um so die Fehlerbehandlung des Kernel zu testen.

Software-Suspend gelingt nun auch mit Swap-Files und arbeitet auf der x86-Architektur jetzt mit Kerneln, die PAE nutzen. 2.6.20 lässt sich speziell auf die Core-Mikroarchitektur optimieren – vollends zum Tragen kommt dies jedoch nur mit Entwicklerversionen der GCC, die das Binary speziell auf Intels aktuelle Prozessor-Architektur optimieren kann. Die Unterstützung für alte Udev-Versionen in Sysfs lässt sich in Zukunft über die Kernel-Konfiguration festlegen

Den in seltenen Fällen seit Kernel 2.6.19 auftretenden Fehler beim Schreiben von Daten korrigierten die Entwickler ebenfalls – bereits zuvor hatte die in der zweiten Januarwoche veröffentlichte Version 2.6.19.2 das Problem behoben, an dessen Beseitigung die Entwickler vier Wochen forschten.

Weiter: Treiber, Ausblick auf 2.6.21, Lesestoff