Unerwarteter Richtungswechsel in der Linux-Entwicklung
23. Juli 2004
Linus Torvalds und Andrew Morton wollen momentan keinen Kernel-2.7-Entwicklerbaum aufbauen und stattdessen den 2.6er Kernel weiter vorantreiben.
In der Linux-Entwickler-Liste ist eine Diskussion dazu entbrannt, wie in Zukunft die Entwicklung des Kernels vorangetrieben werden soll. Sowohl Linus Torvalds als auch der aktuelle Kernel-Maintainer Andrew Morton sehen keinen zwingenden Grund, einen Kernel-2.7-Entwicklerbaum von der aktuellen Version abzuspalten und wollen statt dessen die Entwicklung der aktuellen Version 2.6 vorantreiben. Dies würde einen Paradigmen-Wechsel bei der Entwicklung und Stabilisierung des Linux-Kernels bedeuten.
Bisher wurden Patches, die neue Funktionen, Treiber oder grössere Veränderungen mit sich brachten, über einen langen Zeitraum nicht in den aktuellen Kernel integriert, um dessen Stabilität nicht zu gefährden. Stattdessen wurden die Patches in den Entwicklerbaum integriert. Dies hatte zwei grosse Probleme zur Folge: Einerseits wurde nach einigen Monaten der Patch-Druck so gross, dass gleich eine grosse Anzahl Patches in den jeweils aktuellen Kernel integriert wurde, was zu einer grösseren Instabilität führen konnte. Andererseits haben die Distributoren ihrerseits den Kernel von kernel.org mit den Patches aus dem Entwicklerzweig und Eigenentwicklungen versehen, so dass diese unter Umständen instabiler waren als die Version von kernel.org und man auch nicht ohne weiteres selber ein Kernel-Update machen konnte, ohne das System zu zerlegen.
Nun sollen Patches im –mm-Strang von Andrew Morton, wie seit der Veröffentlichung von 2.6.0 geschehen, getestet und bei ausreichender Stabilität in den aktuellen Kernel integriert werden. Dies sind bis anhin etwa 10 MB pro Monat gewesen. Nach Vorstellung von Torvalds würde dann kernel.org den aktuellsten Kernel zur Verfügung stellen, den die Distributoren nicht wie bis anhin Patchen müssten, sondern nur noch für die nötige Stabilität zu sorgen hätten. Dies würde sicher für einen besseren und aktuelleren Hardware-Support sorgen und dazu führen, dass die Distributionen untereinander kompatibler werden. Wirklich tief greifende Änderungen würde man aber weiterhin in einem abgespaltenem Baum vornehmen und sorgfältig testen, damit man, falls sich die Änderungen als der falsche Weg entpuppen würden, noch immer die Modifikationen verwerfen könnte.
Allerdings ist noch nicht bekannt, wie die Distributoren gedenken, mit den neuen Umständen umzugehen. Besonders die End-User-Distributionen wie Suse, Mandrake oder Fedora Core kennen sehr hohe Release-Zyklen, die bei einer Reifung des Kernels eher hinderlich wären. Auch bestehen Zweifel, ob bei dieser neuen Art der Entwicklung die Anwender genug Vertrauen in den aktuellen Kernel fassen, wenn ein 2.7er Fork fehlt. Bisher galt dies nämlich als Zeichen dafür, dass der aktuelle Kernel noch nicht wirklich einsatzfähig ist. Dazu kommt, dass die Hersteller von Binärmodulen, beispielsweise Nvidia mit ihren Grafikkartentreibern, wenig Freude an der Änderung des Entwicklungsmodus haben dürften. Denn dieser bedeutet, dass in jedem Kernel-Release API- und ABI-Änderungen vorgenommen werden können, denen sie dann hinterher rennen müssten. (IW)
In der Linux-Entwickler-Liste ist eine Diskussion dazu entbrannt, wie in Zukunft die Entwicklung des Kernels vorangetrieben werden soll. Sowohl Linus Torvalds als auch der aktuelle Kernel-Maintainer Andrew Morton sehen keinen zwingenden Grund, einen Kernel-2.7-Entwicklerbaum von der aktuellen Version abzuspalten und wollen statt dessen die Entwicklung der aktuellen Version 2.6 vorantreiben. Dies würde einen Paradigmen-Wechsel bei der Entwicklung und Stabilisierung des Linux-Kernels bedeuten.
Bisher wurden Patches, die neue Funktionen, Treiber oder grössere Veränderungen mit sich brachten, über einen langen Zeitraum nicht in den aktuellen Kernel integriert, um dessen Stabilität nicht zu gefährden. Stattdessen wurden die Patches in den Entwicklerbaum integriert. Dies hatte zwei grosse Probleme zur Folge: Einerseits wurde nach einigen Monaten der Patch-Druck so gross, dass gleich eine grosse Anzahl Patches in den jeweils aktuellen Kernel integriert wurde, was zu einer grösseren Instabilität führen konnte. Andererseits haben die Distributoren ihrerseits den Kernel von kernel.org mit den Patches aus dem Entwicklerzweig und Eigenentwicklungen versehen, so dass diese unter Umständen instabiler waren als die Version von kernel.org und man auch nicht ohne weiteres selber ein Kernel-Update machen konnte, ohne das System zu zerlegen.
Nun sollen Patches im –mm-Strang von Andrew Morton, wie seit der Veröffentlichung von 2.6.0 geschehen, getestet und bei ausreichender Stabilität in den aktuellen Kernel integriert werden. Dies sind bis anhin etwa 10 MB pro Monat gewesen. Nach Vorstellung von Torvalds würde dann kernel.org den aktuellsten Kernel zur Verfügung stellen, den die Distributoren nicht wie bis anhin Patchen müssten, sondern nur noch für die nötige Stabilität zu sorgen hätten. Dies würde sicher für einen besseren und aktuelleren Hardware-Support sorgen und dazu führen, dass die Distributionen untereinander kompatibler werden. Wirklich tief greifende Änderungen würde man aber weiterhin in einem abgespaltenem Baum vornehmen und sorgfältig testen, damit man, falls sich die Änderungen als der falsche Weg entpuppen würden, noch immer die Modifikationen verwerfen könnte.
Allerdings ist noch nicht bekannt, wie die Distributoren gedenken, mit den neuen Umständen umzugehen. Besonders die End-User-Distributionen wie Suse, Mandrake oder Fedora Core kennen sehr hohe Release-Zyklen, die bei einer Reifung des Kernels eher hinderlich wären. Auch bestehen Zweifel, ob bei dieser neuen Art der Entwicklung die Anwender genug Vertrauen in den aktuellen Kernel fassen, wenn ein 2.7er Fork fehlt. Bisher galt dies nämlich als Zeichen dafür, dass der aktuelle Kernel noch nicht wirklich einsatzfähig ist. Dazu kommt, dass die Hersteller von Binärmodulen, beispielsweise Nvidia mit ihren Grafikkartentreibern, wenig Freude an der Änderung des Entwicklungsmodus haben dürften. Denn dieser bedeutet, dass in jedem Kernel-Release API- und ABI-Änderungen vorgenommen werden können, denen sie dann hinterher rennen müssten. (IW)
Artikel kommentieren
