Ein neuer Monat, ein neuer Kernelrückblick. Dieser ist, neben vielen anderen interessanten Themen, in der aktuellen Ausgabe von freiesMagazin enthalten.
Trotz der Ankündigung, auf den letzten Drücker eingereichte Anfragen für die Aufnahme von Patches in den Kernel nicht zu berücksichtigen, ließ Torvalds Gnade walten und pflegte auch verspätete Anfragen ein. Er sei ein zu großer Softie, um anderer Leute Arbeit bis zum nächsten Zyklus zurückzuhalten, schrieb er. Dadurch ließ die zweite Vorabversion sehr zu wünschen übrig und so bestand 2.6.34-rc3 [1] in erster Linie aus Korrekturen für die gröbsten Schnitzer, die sich in -rc2 eingeschlichen hatten. Leider gab es jedoch ein neues Problem, das die Kernel-Entwickler einige Zeit beschäftigen sollte: Änderungen an der Verwaltung des Virtuellen Speichers (VM) führten zu einem Kernel-Oops, der das System jedoch nicht vollständig abstürzen ließ. Die Schwierigkeit bestand darin, dass aus der Riege der Kernel-Entwickler lediglich der AMD-Entwickler Borislav Petkov den Fehler zuverlässig reproduzieren konnte, und so „zu jeder Zeit, Tag und Nacht“ einen Korrekturversuch nach dem anderen testen musste, bis endlich eine Lösung gefunden werden konnte. Daneben wurde auf die Trennung der Abhängigkeit zweier Bibliotheken hingearbeitet. Im ersten Schritt wurde nun überall, wo die Bibliothek percpu.h verwendet wird, auch slab.h eingebunden. Dies passierte in insgesamt über 4000 Dateien und war damit zumindest die auffälligste Änderung an -rc4 [2]. Mit -rc5 [3] kehrte dann wieder etwas mehr Ruhe ein. Die üblichen Fehlerkorrekturen, um den Kernel zu stabilisieren, wurden von Aufräumarbeiten am Intel-Treiber i915 begleitet, die in erster Linie kosmetischer Natur sind. Hier wurde ein Klasse [4] umbenannt, um den veränderten Strukturen des DRM (Direct Rendering Managers) im Vergleich zu UMS (User Mode Setting), auf dessen Basis ein großer Teil des i915-Codes aufgebaut wurde, Rechnung zu tragen.
Der Rauswurf der Android-Treiber aus dem staging-Zweig hat kurze Zeit hohe Wellen geschlagen (siehe „Der Februar im Kernelrückblick“, freiesMagazin 03/2010 [5]). Bereits kurz darauf kam der erste Dialog zwischen den Android-Entwicklern und Greg Kroah-Hartmann zustande, um langfristig die Wiederaufnahme der Android-spezifischen Anpassungen in den Linux-Kernel zu erreichen (siehe „Der März im Kernelrückblick“, freiesMagazin 04/2010 [6]). Nun möchte Google zwei Entwickler mit der Aufgabe betrauen, Änderungen am Linux-Kernel für den Einsatz mit Android in den offiziellen Kernel zurückzuführen [7].
Die stabilen Kernel 2.6.32 und 2.6.33 können beide mit Verbesserungen am freien Radeon-Treiber aufwarten. Fehlerkorrekturen in 2.6.32.12 beheben darüber hinaus noch ein Speicherleck der Virtualisierungslösung KVM und verbessern die Unterstützung für Asus-EeePCs und IBM-Thinkpads [8]. 2.6.33.3 bringt unter anderem Korrekturen für die Dateisysteme ecryptfs, xfs und ocfs2 mit [9].
Eine Aktualisierung hat Xen mit der Version 4 erfahren [10]. Bislang unterstützte die Virtualisierungslösung lediglich den etwas angestaubten Kernel 2.6.18 für das Host-System, auch wenn einige Linux-Distributoren entsprechende Anpassungen für die von ihnen gelieferten aktuelleren Kernel bereitstellten. Mit Version 4.0 kommt nun standardmäßig 2.6.31 zum Einsatz, aber auch 2.6.32 soll zur Verfügung stehen. Da die Kernel-Erweiterungen von Xen bislang nicht in den offiziellen Kernel aufgenommen wurden, könnte sich eine solche Aktualitätslücke jedoch wieder auftun und die Anwender vor die Wahl stellen, entweder einen aktuellen Kernel anzupassen oder mit einem älteren zu arbeiten.
Kurz erläutert: „Kernel Oops“ / „Kernel Panic“Ein „Kernel Oops“ ist ein Fehler in der Funktion des Linux-Kernels. Dabei muss es sich nicht unbedingt um einen Software-Fehler handeln; wenn eine Hardware unerwartet reagiert, kann dies ebenfalls zu einem Oops führen. Das System kann trotz eines Oops manchmal weiterarbeiten. Ein Oops erzeugt normalerweise eine Fehlermeldung mit einer kurzen Beschreibung, was vorgefallen ist, und technischen Informationen, wie Speicherauszügen oder den vom Prozessor ausgeführten Code, die bei der Eingrenzung des ursächlichen Problems helfen sollen. Das Kernel-Oops-Projekt [11] hat es sich zur Aufgabe gemacht, die häufigsten Ooops zu finden und zu beheben.
Ein „Kernel Panic“ ist dagegen ein schwerwiegender Fehler, der nicht vom Betriebssystem selbst behoben werden kann. Im Falle eines „Kernel Panic“ wird in der Regel ein Abbild des Kernels zum Zeitpunkt des Absturzes zur späteren Analyse gespeichert und eine Fehlermeldung angezeigt. Meist bleibt bei einem „Kernel Panic“ nur der Neustart des Systems übrig.
Quellen:
[1] [lkml.org]
[2] [lkml.org]
[3] [lkml.org]
[4] [de.wikipedia.org]
[5] [www.freiesmagazin.de]
[6] [www.freiesmagazin.de]
[7] [www.heise.de]
[8] http://lkml.org/lkml/2010/4/26/118
[9] [lkml.org]
[10] [www.linux-magazin.de]
[11] [www.kerneloops.org]
