Open Source im professionellen Einsatz
Linux-Magazin 06/2013

Kernel-News

Zacks Kernel-News

1425

Perl-Abhängigkeit beim Kernelbuild

Rob Landley hat kein Glück mit seinen Patches, die Perl als Abhängigkeit beim Bauen des Kernels entfernen sollen. Wie er erinnerte, hatten die Entwickler mit Linux 2.6.25 einige Perl-Skripte in das Buildsystem eingeführt. Will also jemand Linux ab Version 2.6.25 kompilieren, muss er Perl installieren – vor dieser Kernelversion war das nicht nötig. Robs Patches ersetzen nun die vorhandenen Perl-Skripte durch einfache Shellskripte. Er habe – schrieb er in seiner E-Mail – die Patches wieder und wieder gepostet, doch es interessiere sich niemand für sie.

Andrew Morton erwiderte, er sehe nicht, warum eine Perl-Abhängigkeit ein Problem für jemanden darstellen sollte. Die Entscheidung, die Perl-Skripte zu entfernen, sei logischerweise zugleich eine Art Entscheidung dafür, auch in Zukunft alle Perl-Abhängigkeiten zu löschen, was einiges an Arbeit und Fleiß erfordere. Von Rob wollte er daher wissen, was dessen Motivation für das Veröffentlichen dieser Patches sei.

Linux-Urgestein Andrew Morton, hier auf dem Linuxtag 2006, befürchtet, das Entfernen der Perl-Skripte könne einen Präzedenzfall schaffen.

Rob antwortete: "Es handelt sich um komplett überflüssige Abhängigkeiten für die Buildumgebung, und der Kernel hat eine Tradition, solche zu entfernen." Er ergänzte, seine Shellskripte wären mindestens so einfach, wenn nicht einfacher als die zu ersetzenden Perl-Skripte. Dank der Patches würde man also nicht nur die Abhängigkeiten auflösen, sondern auch den Kernel vereinfachen. Rob fuhr fort, dass die Perl-Abhängigkeiten auch Cross Compiling – das ohnehin eine delikate Angelegenheit sei – fehleranfälliger machten.

Die große Diskussion auf der Mailingliste blieb jedoch aus, offenbar gibt es Widerstand gegen den Rauswurf der Perl-Abhängigkeit. Die Vermutung liegt nahe, dass eine signifikante Gruppe von Kernelentwicklern Perl in ihrer Buildumgebung nutzen will, sonst wäre die Integration von Robs Patches eine Selbstverständlichkeit. Normalerweise sind weniger Buildabhängigkeiten besser als mehr, aber das gilt offenbar nicht, wenn es sich um wichtige Abhängigkeiten handelt.

Der Workflow nach dem Kernel.org-Einbruch

Der Einbruch in Kernel.org vom August 2011 beeinflusst noch immer den Workflow einiger Kernelentwickler. Nachdem die Kernel.org-Admins alle Dienste abgesichert hatten, implementierten sie nur einen Bruchteil der Features – im Vergleich zu der Zeit vor dem Einbruch – neu. Vor allem erhalten nur noch solche Benutzer Konten, die ihre Identität über einen signierten Krypto-Key ausweisen, was mitunter zu Problemen führt.

So registrierte Paul Gortmaker neulich einen Haufen neuer Dateien im Dokumentationsverzeichnis des Kernel-Source-Zweigs, die nicht in der »00-INDEX« -Datei dieses Ordners auftauchen. Er schickte ein Patch, um die Datei zu aktualisieren.

Rob Landley antwortete ihm: "Ich habe ein Skript, das HTML-Nagivationsseiten aus den »00-INDEX« -Dateien erstellt, und ein weiteres, das dieses parst, um tote Links in beiden Verzeichnissen zu entdecken, also Dateien ohne Eintrag in der »00-INDEX« -Datei und »00-INDEX« -Einträge, die auf nicht existierende Dateien verweisen. Ich habe es seit Ewigkeiten nicht laufen lassen, weil die Kernel.org-Leute allen die Konten weggenommen haben."

Wütend fährt er fort: "Die geben mir ohne Bluttest oder Ähnliches keinen neuen SSH-Key. Und selbst wenn ich durch diesen Reifen springen würde, verpacken sie SSH in einem Git-Wrapper, wodurch Rsync nicht mehr funktioniert, weshalb ich »kernel.org/doc/Documentation« ohnehin nicht mehr aktualisieren könnte." Als Ausblick fügte er hinzu: "Ich hab kübelweise Dinge, die ich in diesem Verzeichnis tun würde, aber kein Kernel-Konto mehr."

Es lässt sich zwar leicht nachvollziehen, dass Entwickler unglücklich darüber sind, ihren Workflow ändern zu müssen. Aber es ist auch klar, dass die meisten Kernelentwickler lediglich Patches an die Mailingliste schicken. Der Einbruch ist fast zwei Jahre her, es wäre also für diese Minderheit der Entwickler an der Zeit, nach vorn zu blicken.

Code für linux-next?

Von James Hogan kamen einige Patches, um Linux auf die Prozessorkerne Meta ATP und Meta HTP von Imagination Technologies zu portieren. Diese Multithread-Universalprozessoren kommen oft in Digitalradios zum Einsatz. Arnd Bergmann schaute sich die Codeflicken an und erklärte, er könne keine Show-Stopper darin finden. Seiner Meinung nach sei James Arbeit so weit, in den Kernel 3.9 zu wandern.

Die interessantere Diskussion in dem Thread entspann sich jedoch um die Prozesse in der Kernelentwicklung. So basierte James erstes Patchset auf dem »linux-next« -Zweig. Das erscheint vernünftig, weil der von ihm geschickte Code ja in diesem Zweig landen sollte. Stephen Rothwell erklärte aber, dass sich die Kernelentwicklung auf Linus Torvalds offiziellen Zweig stützen müsse. Der Zweig »linux-next« sei nur eine Sammlung für Dinge auf ihrem Weg in Linus' Zweig und dürfte nicht als Entwicklungsziel dienen.

Daraufhin entgegnete James, dass seine Portierung von Code abhänge, der nur im »linux-next« -Zweig existiere und der bisher noch nicht in den offiziellen Zweig von Linus integriert worden sei. Er erkundigte sich auch, ob der offizielle Weg darin bestehe, die benötigten Codeteile aus »linux-next« in den eigenen Tree zu kopieren, um den eigenen Code am Laufen zu halten und ihn dann an Stephen weiterzureichen.

Stephen bejahte das für den Fall, dass der Code in »linux-next« eine echte Abhängigkeit sei und James' Patch nicht nur einen Konflikt behebe. Falls das Patch mit dem Code in »linux-next« in Konflikt stünde, solle er sich darüber keinen Kopf machen, sondern den Konflikt von Stephen oder Linus im Laufe des Merge-Prozesses beheben lassen. Hinge James' Code hingegen legitim von dem in »linux-next« ab, soll er keine Skrupel haben, ihn in den eigenen Zweig aufzunehmen. Doch ermahnte er James, die relevanten Maintainer davon zu informieren, dass er keinen Rebase ihrer Trees plane.

Rebasing bedeutet, dass ein Entwickler mit Hilfe von Git einen Entwicklerzweig in einen anderen integriert, indem er die Patches direkt von einem in den anderen Zweig spielt, um den ursprünglichen Zweig wegzuwerfen. Rebasing verändert die Historie eines Git-Repository, was Stephens Rat an James erklärt.

Stephen Rothwell erklärte auf der Mailingliste, was es mit linux-next auf sich hat (Quelle: Julien/Linux Foundation, CC-BY-SA 3.0).

Stephen antwortete darauf, seine »linux-next« -Abhängigkeiten seien tatsächlich eher trivial und er könne seine Patches auch problemlos ohne die Abhängigkeiten schicken, wenn dieser Ablauf das Leben erleichtere. Er wolle die Änderungen dann demnächst einfügen.

In diesem Zusammenhang kam auch die Frage auf, wann jemand seinen Code als ausgereift genug betrachten dürfe, um ihn an »linux-next« zu schicken. Stephens einfache Antwort lautete: Wenn der Code bereit sei, in Linus' Hauptzweig zu wandern, sei er auch bereit für »linux-next« . Letzterer Zweig sei im Endeffekt nichts anderes als eine Staging-Zone für Code auf dem Weg zu Linus.

Hotplug: Großreinemachen und Neubau

Thomas Gleixner behauptete in einem Beitrag, dass die CPU-Hotplug-Implementierung nach und nach aus dem Ruder gelaufen sei mit ihrer Vielzahl an Race Conditions, undokumentierten Verhaltensweisen und anderem Wahnsinn. Er postete daher ein Bündel an Patches, um den ganzen Komplex zu überarbeiten und eine vorhersagbare Zustandsmaschine zu schaffen, die Symmetrie in den Start- und Abbruchprozess bringen soll.

Linus Torvalds kritisierte die Patches jedoch: Er wolle vor allem sicherstellen, dass Thomas den kompletten Weg gehe, ohne sich zurückzuhalten. Offenbar hasst Linus die aktuelle Hotplug-Implementierung und ist der Meinung, dass eine Reihe von Hotplug-Verhaltensweisen dem Nutzer überhaupt nicht zugänglich sein sollte, sondern hinter einen Vorhang gehöre, wo man sie in Ruhe ausradieren könne.

Das deckt sich mit Thomas' Ziel. Er versichert Linus, er wolle die komplette Hotplug-Benachrichtigungskette entfernen, zusammen mit einer Myriade nicht zurückverfolgbarer Notifier-Implementierungen für die Benutzer, die sich wie Flechten um den Hotplug-Code legen: "Das aktuelle Hotplug-Gestrüpp kennt mehr als 100 komplett undokumentierte Zustände. Sie verhalten sich asymmetrisch zu den Startup- und Teardown-Prozessen. Sie existieren einfach und arbeiten oft abseits der nur schwer entwirrbaren Problemchen."

Er wolle den ganzen Schlamassel durch nur zwei für den User sichtbare Zustände ersetzen: »CPUHP_PREP_Datenstruktur« , um die Datenstrukturen aufzusetzen und freizumachen, sowie »CPUHP_ENABLE_CPU-Zeug« , um die Hotplug-Fähigkeit ein- und auszuschalten.

Der Rest von Thomas' Zustandsmaschine wäre für Nutzer unsichtbar, man könne sich später darum kümmern. Rusty Russell formulierte in einer Anspielung auf Thomas' erste Mail: "In Episode II bringen wir dann, wie es Thomas sagt, alles in einen gesunden Zustand zurück. Das ergibt Sinn, weil ich es hassen würde, alles auf einmal zu erledigen." (Zack Brown/kki)

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 2 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Kernel-News

    Die Entwickler des Linux-Kernels organisieren ihre Arbeit per Mailingliste. Aus der Flut der Nachrichten, Patches und Diskussionen fischt Zack Brown für das Linux-Magazin regelmäßig die interessantesten Threads heraus.

  • Kernelentwicklung: Linux-next fertig

    Der neue Git-Tree namens "linux-next", der die Kernelentwicklung vereinfachen und beschleunigen soll, ist weitgehend fertiggestellt.

  • Kernel-Next: Zwischenstufe für höhere Effizienz

    Andrew Morton hatte einen Traum: Ein neuer Kerneltree, der die Kernelentwicklung übersichtlicher und effizienter macht. Er suchte einen Maintainer und hat ihn in Stephen Rothwell gefunden.

  • Kernel-News

    Zacks Kernel-News

  • Linus' Dirigent

    Große Softwareprojekte haben ihre eigenen Regeln, denn Hunderte von Entwicklern und Millionen Zeilen Code wollen koordiniert sein. Das Linux-Magazin fragte beim ranghöchsten Maintainer des aktuellen Linux-Kernels nach, wie er das bewerkstelligt.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.