Kernel-Log: OEM-Hersteller fordern Open-Source-Treiber, KVM mit 2.6.26 aufgebohrt

Verschiedene PC- und Notebook-Hersteller wollen Hardware-Produzenten künftig zur Entwicklung von Open-Source-Treibern drängen. Torvalds integrierte zahlreiche Verbesserungen für KVM und Xen in den Hauptentwicklungszweig von Linux.

186

29.04.2008, 11:22 Uhr

Lesezeit: 7 Min.

Von

Thorsten Leemhuis

Die Linux Foundation hat einen Konferenzbericht vom kürzlich abgehaltenen Annual Collaboration Summit vorgelegt. Canonical, Novell, Red Hat und andere haben demnach eine "Driver Backporting Workgroup" gebildet – sie will sich unter anderem um das Zurückportieren von für aktuelle Linux-Versionen entwickelte Open-Source-Treiber auf ältere Kernel-Versionen kümmern, da sie von vielen Firmen im Linux-Umfeld eingesetzt werden. Auch will die Gruppe die Verteilung und Installation von Treibern optimieren.

Verschiedene PC- und Notebook-Hersteller waren sich zudem darin einig, die Hersteller von Chipsätzen und anderen Hardware-Komponenten in Zukunft nachhaltig zur Entwicklung von Open-Source-Treibern zu drängen. Dazu wollen die Unternehmen ihre Ausschreibungen anpassen und dort die Hersteller dazu auffordern, Open-Source-Treiber zur Integration in den Linux-Kernel bereitzustellen. Der Bericht erwähnt auch das kürzlich veröffentlichte Open-Source-Engagement des Chipsatzherstellers VIA. Die damals von VIA angekündigte Web-Seite ging gestern als "Beta" Online. Von Dokumentation oder Quellcode ist dort allerdings nichts zu sehen – statt dessen gibt es nur zwei Treiber, die für zwei Distributionen vorkompiliert wurden.

In den vergangenen Tagen hat Linus Torvalds derweil zahlreiche weitere Patches in den Hauptentwicklungszweig eingepflegt, aus dem ungefähr Anfang Juli die Linux-Version 2.6.26 hervorgehen wird. Unter anderem integrierte er die von Avi Kivity gesammelten Patches, die die Virtualisierungslösung KVM (Kernel-based Virtual Machine) wieder einmal erheblich erweitern. So wird das im Kernel enthaltene KVM mit 2.6.26 erstmals die Architekturen IA64 (1, 2, Dokumentation) und s390 (1, 2, Dokumentation) sowie PowerPC-Prozessoren der 44x-Reihe unterstützen – bislang arbeitet KVM nur auf 32- und 64-Bit-x86-Prozessoren. Für diese gab es ebenfalls zahlreiche Verbesserungen – etwa die für FreeDOS benötigte Emulation von Hardware Task Switching sowie Unterstützung für die in neueren Prozessoren enthaltenen Virtualisierungstechniken Nested Page Tables (1, 2, 3) von AMD und Virtual Processor Identification (VPID) von Intel.

Auch an der KVM-Infrastruktur gab es ähnlich wie bei den vorangegangenen Kernel-Versionen wieder zahlreiche Verbesserungen, von denen viele Kompatibilität oder Performance verbessern sollen; dazu zählen etwa grundlegende Paravirt-Unterstützung (etwa 1, 2, 3, 4) Large Page Support, PIT Emulation im Kernel und das Performance-Tracing-System kvmtrace (1, 2). Zudem gilt KVM nun nicht mehr als Experimentell. Kürzlich veröffentlichten die KVM-Entwickler auch die KVM-Version 67, die viele der jetzt für Linux 2.6.26 aufgenommenen Änderungen bereits zum Nachkompilieren als Modul für ältere Kernel mitbringt.

Torvalds integrierte auch die zuvor von Ingo Molnar gesammelten Patches für den seit [#97154 2.6.23] im Kernel enthaltenen Code zum Betrieb von Linux als Gast unter Xen Host-Systemen. Darunter war unter anderem der Balloon Driver, über den sich die vom Gast-System zugewiesene Speichermenge reduzieren lässt. Auch die paravirtualisierten Framebuffer-, Tastatur- und Maus-Treiber (xen pvfb) pflegten die Entwickler ein. Nachdem es um das IDE-Subsystem zeitweise still geworden war, hat der für den IDE-Code zuständige Entwickler Bartlomiej Zolnierkiewicz in den vergangenen Monaten viele Bereiche im IDE-Code überarbeitet und dabei aufgeräumt; viele weitere Detail-Verbesserungen fanden in den vergangenen Tagen den Weg in die Hauptentwicklungslinie des Linux-Kernels. Somit wird das IDE-Subsystem wohl weiter parallel zu den neueren im Libata-Subsystem angesiedelten PATA-Treibern erhalten bleiben, die sich ebenfalls um IDE-Adapter kümmern.

Ausgiebige Diskussionen über Code und die Koordination bei der Entwicklung sind auf der Linux-Kernel Mailing List (LKML) nichts ungewöhnliches; derzeit stechen aber zwei Debatten hervor. Dave S. Miller und James Bottomley etwa kritisierten in den vergangenen Tagen wiederholt Ingo Molnar, der seit einigen Monaten einer der Betreuer des x86-Architektur-Codes ist. Einige der zahlreichen über Molnar eingebrachten Änderungen seien den beiden Kritikern zufolge nicht ausreichend geprüft (reviewed) worden. Ob es sich so verhält, lässt sich nur schwer feststellen, denn Molnar arbeitet enorm schnell und war bei letzten Entwicklungszyklen jeweils Gateway für hunderte verschiedener Patches.

Eine zweite Debatte startet eine von Adrian Bunk geschriebene E-Mail mit provokantem Titel. In dieser kritisierte er unter anderem, dass ein von ihm geschriebener Patch nicht angenommen wurde und dadurch wieder einmal doppelte Arbeit entstanden sei, weil ein anderer Entwickler einen ähnlichen Patch programmierte, um ein Problem zu beheben; andere Korrekturen hätte er zudem bereits sieben Mal an die LKML gesandt, ohne dass der Patch angenommen wurde. Einige dieser und anderer Probleme waren wohl aus Missverständnissen entstanden und konnten ausgeräumt werden. In letzter Zeit häufen sich solche Debatten jedoch – daran dürfte nicht zuletzt die im vergangenen Jahr enorm gestiegenen Rate an pro Entwicklungszyklus eingepflegten Änderungen mit Schuld sein.

Kernel-Log-Staccato:

Der bei Tungsten Graphics beschäftigte Entwickler José Fonseca erläutert in seinem Blog Hintergründe zu Gallium3D – einer Basis-Architektur für zu verschiedenen APIs und Betriebssystemen kompatible 3D-Grafiktreiber.
Jan Engelhardt hat auf der LKML für 2.6.25 angepasste Patches veröffentlicht, mit denen der Kernel Warnmeldungen oder Fehlerinformationen in anderen Farben darstellt als einfachen Status-Ausgaben. Diese "Colored-Kernel-Output"-Patches pflegt er schon länger unabhängig vom offiziellen Kernel – einige bekannte Entwickler hatten sich zwar für die Integration der Patches ausgesprochen, bisher ist es dazu aber nicht gekommen.
Der Verwalter der 2.4-Kernelserie bittet um Feedback von Anwendern, die immer noch 2.4-Kernel einsetzen, damit er die Weiterentwicklung besser auf die Anwender abstimmen kann.

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich auch in den vorangegangen Ausgaben des Kernel-Logs auf heise open: