Kernel-Log: Erster Release Candidate von Linux 2.6.39
Torvalds stuft 2.6.39 als eher solide Version mit langweiligen Fortschritten ein. Mit Unterstützung für Ipset, dem Xen-Netzwerk-Backend sowie vielen neuen und überarbeiteten Treibern bringt die Ende Mai oder Anfang Juni erwartete Version aber durchaus wichtige Verbesserungen.
- Thorsten Leemhuis
Fünfzehn Tage nach der Freigabe von Linux 2.6.38 hat Linus Torvalds das Merge Window von Linux 2.6.39 mit der Veröffentlichung von 2.6.39-rc1 geschlossen und damit die Aufnahme der größten Änderungen für 2.6.39 beendet. Am Ende der Freigabe-Mail erwähnt Torvalds, er habe den Eindruck, dies sei eine der soliden Versionen mit langweiligen Fortschritten ('But on the whole I think this should be one of those "solid, boring progress" releases.'); bei 2.6.38 hatte er sich über die Autogruppierung von Prozessen und die Optimierungen am VFS aber auch ungewohnt begeistert gezeigt.
Änderungen gab es allerdings wie üblich reichlich – das zeigt auch der Diffstat, laut dem die Kernel-Hacker schon bei der ersten Vorabversion von Linux 2.6.39 mehr Zeilen Code aufgenommen, entfernt oder umhergeschoben haben als bei 2.6.38:
- 2.6.38: 9158 files changed, 748179 insertions(+), 455943 deletions(-)
- 2.6.39-rc1: 8995 files changed, 828740 insertions(+), 509303 deletions(-)
Das Kernel-Log in c't und auf heise open wird in den kommenden Wochen detailliert über diese und zahlreiche weitere Neuerungen von Kernel 2.6.39 berichten. Torvalds dürfte den neuen Kernel Ende Mai oder Anfang Juni freigeben, wenn er und seine Mitstreiter im üblichen Tempo arbeiten.
Einblicke
Einige Diskussionen auf der Linux Kernel Mailing List während der Hauptentwicklungsphase von 2.6.39 erlauben tiefere Einblicke in einige Aspekte der Kernel-Entwicklung. So schreibt Torvalds in der Freigabe-Mail zum RC1, der Kernel habe zwischendurch "XFS-Dateisysteme zum Frühstück gegessen", was aber nun behoben sei. Das zeigt eine der Gefahren beim Testen von Vorabversionen des Kernels – solch gravierende Probleme treten allerdings nur selten auf. Typischerweise werden sie schnell korrigiert, um die ohnehin schon raren Tester nicht zu verschrecken; nach unseren Erfahrungen ist die Gefahr von Datenverlust ab dem RC2 kaum größer als beim Einspielen einer fertigen Kernel-Version.
Wie sich Torvalds gelegentlich dafür einsetzt, dass auch Details stimmen, zeigt seine Antwort auf einen von Rafael J. Wysocki abgesetzten Git-Pull-Request. Letzterer enthielt Patches, welche die Konfigurationsoptionen für die Power-Management-Funktionen des Kernels umstrukturierten. Torvalds gefielen allerdings einige Aspekte nicht: Es sei idiotisch Anwender zu fragen, ob sie "Schnittstellen für Funktionen wollen, die für den Ruhezustand zuständig sind". Das kümmere Anwender nicht und sei auch nichts, worum sie sich zu kümmern hätten – sie wollten einfach Hibernate-Support.
Grafiktreiber-Probleme, Versionsstatus, Staccato
Problemfeld Grafiktreiber
In einer weiteren LKML-Diskussion hat Linus Torvalds darauf hingewiesen, dass der im Merge Window aufgenommenen Code vor Beginn des Merge Window entwickelt und getestet werden solle. Den einzigen neuen Code, den er in der Hauptentwicklungsphase sehen wolle, sei solcher, der Fehler beseitigt. Auslöser war der Git-Pull-Request für das DRM-Subsystem, der einen kurz zuvor erschienenen Patch enthielt, an dem ein andere Entwickler einen Aspekt kritisiert hatte.
Dave Airlie erklärte daraufhin, der diskutierte Patch sei die Aufregung nicht wert. Der Verwalter des DRM/KMS-Subsystems gestand aber ein, gelegentlich jungen Code zur Aufnahme einzusenden, weil er Fehler in Treiber-Code beseitige, der bei der letzten Version aufgenommen wurde, oder weil er die Hardware-Unterstützung verbessere; würde er solche Sachen zurückhalten, dann käme der Code erst sechs Monate später bei den Anwendern an. Er führt die Gründe noch weiter aus und erwähnt Überlegungen, die Treiber wieder unabhängig vom Kernel zu entwickeln – das würde aber ganz andere Probleme mit sich bringen. Auch Jerome Glisse, der an dem Radeon-Treiber mitarbeitet, meldete sich zu Wort und erwähnte etwa, dass ein stabiles Kernel-API für DRM-Treiber seiner Ansicht nach keine gute Lösung sei. Die Diskussion führte letztlich zu nichts, zeigt aber einige der Probleme, mit denen die Entwickler der Grafiktreiber für Kernel, Mesa 3D und X.org zu kämpfen haben.
Kernel-Versionsstatus
Greg Kroah-Hartman hat die Stable-Kernel 2.6.38.2 und 2.6.37.6 sowie den Longterm-Kernel 2.6.32.36 freigegeben; wenig später legte er dann noch den als Basis für die Echtzeit-Erweiterungen aus dem RT-Tree interessanten Kernel 2.6.33.9 nach. Die ersten drei enthalten wie üblich den nachdrücklichen Aufruf zum Update auf die neuste Version. Die Pflege der 37er-Serie stellt Kroah-Hartman mit 2.6.37.6 ein, daher ruft er in dessen Freigabe-Mail zusätzlich zum Wechsel auf den neuen 38er-Kernel auf.
Kernel-Log-Staccato
Kernel
- Greg Kroah-Hartman weist in seinem Blog darauf hin, dass der Kernel nun schon seit einigen Versionen eine Locking-Lösung bietet, die mit den vom Android-Kernel genutzten Wakelocks (auch Suspend Blocker genannt) vergleichbar ist – über die wurde vergangenes Jahr lange und kontrovers diskutiert. Es gäbe daher keine großen Hürden bei der Aufnahme von Kernel-Treibern, die für Android geschrieben wurden. Kroah-Hartman fordert dazu auf, solche Treiber zur Aufnahme einzusenden.
- Einige Kernel-Hacker wiesen kürzlich den Vorschlag des ACPI-Subsystem-Verwalters zurück, die Unterstützung für APM (Advanced Power Management) bei 2.6.40 aus dem Kernel zu werfen; die später aufgekommenen Idee, die Unterstützung für APM Idle zu entfernen, fand jedoch selbst die Zustimmung von Linus Torvalds.
- Jon Masters hat den in den letzten Monaten eingeschlafenen Linux Kernel Podcast wieder reaktiviert; in der Niederschrift des Podcasts für die vergangene Woche erwähnt er unter anderem eine LKML-Diskussion zu SMBIOS und DMI oder den Vorschlag zum Entfernen der APM-Unterstützung.
Unterstützung für Grafikhardware
- Jeremy Huddleston hat eine Vorabversion des X-Server 1.10.1 freigegeben, die durch Beseitigen einiger Fehler stabiler laufen soll.
Kernel-Umland ("Plumbing layer"), Userland-Treiber, Entwicklertools, ...
- Die Entwickler des Projekts Hplip (Hewlett-Packard's Linux Imaging and Printing Software) haben die Version 3.11.3a des gleichnamigen Treiber-Pakets für Drucker und Multifunktionsgeräte von HP veröffentlicht, die einen Fehler der Version 3.11.3 behebt.
- Junio C Hamano hat Git 1.7.4.2 freigegeben.
- Neil Brown hat das als Stabil eingestufte mdadm 3.1.5 veröffentlicht, das einige Fehler beseitigt, die er bei der Arbeit an den Versionen 3.2.0 und 3.2.1 entdeckt hat; letztere soll bald erscheinen.
- Die bridge-utils 1.5 bieten erstmals einen 'hairpin' genannten Modus zum Port-Forwarding. Stephen Hemminger erwähnt im Rahmen der Freigabe-Mail, dass dies wohl die letzte Version der Werkzeug-Sammlung zur Bridge-Konfiguration sei; er arbeite daran, auf Netlink aufsetzende Bridge-Tools in iproute2 zu integrieren.
- Jean Delvare listet in der Freigabe-Mail zu lm-sensors 3.3.0 dessen wichtigsten Neuerungen auf – etwa das Ansprechen von Sensoren zur Bestimmung der Luftfeuchtigkeit oder solchen zur Intrusion Detection. Die Version unterstützt zudem einige der Funktionen, die neuere Treiber zum Hardware-Monitoring bieten.
