Menü

Kernel-Log: Linux-next soll die Entwicklungsarbeit koordinieren

vorlesen Drucken Kommentare lesen 61 Beiträge

Stephen Rothwell versucht in Absprache mit Andrew Morton durch die Einrichtung der für Linux-Entwickler gedachten Kernel-Linie Linux-next den steten Fluss der für die Integration in den Linux-Kernel vorgesehenen Neuerungen besser in den Griff zu bekommen. Bislang bereiteten die Verwalter der Linux-Subsysteme wie IA64, PPC, PCI, USB, SCSI, ATA, IDE oder Kbuild ihre Verbesserungen zumeist unabhängig voneinander in subsystemspezifischen und mit git oder quilt verwalteten Entwicklerzweigen vor; von dort gelangen sie dann in den von Andrew Morton gepflegten mm-Entwicklerkernel. In den ersten zwei Wochen des Linux-Entwicklungszyklus integriert Torvalds dann während des sogenannten "merge window" die größeren Neuerungen in das Linux-Quellcodeverwaltungssystem – dabei greift er teilweise nicht direkt auf die subsystemspezifischen Entwicklerzweige zurück, sondern auf davon wiederum abgeleitete Entwicklerzweige, in denen die Subsystemverwalter nur die Patches einpflegen, die sie als ausgereift für den offiziellen Kernel einschätzen.

Aus dem von Torvalds betreuten Linux-Quellcodeverwaltungssystem geht dann nach der zirka zwei Monate dauernden Testphase die nächste Kernel-Version hervor – der von Torvalds verwaltete Entwicklerzweig ist daher sozusagen die Spitze des Linux-Entwicklerbaumes. Der Zyklus beginnt anschließend von neuem. Während dieser zwei Monate veröffentlicht Morton neue, vom Hauptstamm abgeleitete mm-Kernel mit den verschiedenen subsystemspezifischen Entwicklerzweigen; zudem integriert er noch manch andere experimentelle Neuerungen. Der mm-Kernel enthält dadurch viel Code, der noch Monate oder Jahre reifen muss, bevor er gut genug für den offiziellen Kernel ist – das Reiser4-Dateisystem ist etwa schon über zwei Jahre nur in den mm-Kerneln enthalten, die durch die zahlreichen experimentellen Erweiterungen gerne mal kleinere oder größere Probleme mit sich bringen und daher nicht für Endanwender gedacht sind.

Der Linux-next-Zweig soll die Lücke zwischen dem von Linus Torvalds und dem von Andrew Morton gewarteten Kernel-Zweigen nun schließen, indem er nur Patches enthalten soll, die mit größter Wahrscheinlichkeit reif für die übernächste Kernel-Version sind. So würde Stephen Rothwell dann mit Linux-next derzeit die Neuerungen für 2.6.26 sammeln, während Torvalds parallel weiter an 2.6.25 arbeitet und Morton im auf Linux-next aufbauenden mm-Kernel die experimentelle Erweiterungen zusammenfasst, die erst für 2.6.27 oder später infrage kommen. Dieses Schichtsystem entlastet Morton bei seiner Arbeit und soll den Subsystemverwaltern helfen, ihre Arbeit besser zu koordinieren, da die Subsysteme nicht immer klar voneinander getrennt sind und teilweise miteinander interferieren. Dadurch dürfte Linux-next auch dafür sorgen, dass Torvalds zu Beginn des Entwicklungszyklus ausgereifte und aufeinander abgestimmte Patches und Entwicklerzweige vorfindet, die er ohne größere Schwierigkeiten in den Hauptstamm der Linux-Entwicklung integrieren kann.

Eine Linux-next-ähnliche Idee hatte der Verwalter des SCSI-Subsystems James Bottomley vor Kurzem mit dem "merge-tree" angekündigt – so wie es aussieht, wird Rothwell nun die Arbeit aber mit Linux-next fortführen. Die Diskussion um Linux-next uferte schnell in eine allgemeine Debatte darüber aus, wie die Subsystemverwalter ihre Arbeit am besten koordinieren und wie sie Git nutzen sollen, ohne anderen Entwicklern des Subsystems allzuviel Umstände zu bereiten.

Kernel-Log Staccato: Nachdem Intel vor kurzem die Dokumentation für die Grafikkerne der aktuellen Intel-Chipsätze veröffentlicht hat, stellt nun auch AMD die bereits vor einigen Monaten erstmals an Entwickler verteilte Dokumentation für einige GPUs geordnet auf die eigene Webseite; zudem hat das Unternehmen eine E-Mail-Adresse für Rückfragen zu den Dokumenten eingerichtet.
Die bereits zuvor im Kernel-Log erwähnten Diskussionen um die Aufnahme von KGDB kochen unter Beteiligung von Torvalds auf hoher Stufe weiter – ein Ende ist nicht in Sicht.
Die heißen Debatten um das für 2.6.25 vorgesehene Aussperren von proprietären USB-Treibern sind derweil abgeflaut – Überraschungen gab es dabei keine, daher sieht es derzeit so aus, als würde der Patch wohl im offiziellen Linux-Kernel bleiben.

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: