In Continuous Integration Testing für den Linux-Kernel , habe ich über das Continuous Kernel Integration (CKI)-Projekt und seine Mission geschrieben, die Arbeitsweise von Kernel-Entwicklern und -Maintainern zu ändern. Dieser Artikel gibt einen tiefen Einblick in einige der eher technischen Aspekte des Projekts und wie alle Teile zusammenpassen.
Alles beginnt mit einer Veränderung
Jedes aufregende Feature, jede Verbesserung und jeder Fehler im Kernel beginnt mit einer von einem Entwickler vorgeschlagenen Änderung. Diese Änderungen erscheinen auf unzähligen Mailinglisten für verschiedene Kernel-Repositories. Einige Repositories konzentrieren sich auf bestimmte Subsysteme im Kernel, wie z. B. Speicher oder Netzwerke, während andere sich auf breite Aspekte des Kernels konzentrieren. Das CKI-Projekt tritt in Aktion, wenn Entwickler eine Änderung oder ein Patchset für den Kernel vorschlagen oder wenn ein Betreuer Änderungen im Repository selbst vornimmt.
Das CKI-Projekt verwaltet Auslöser, die diese Patchsets überwachen und Maßnahmen ergreifen. Softwareprojekte wie Patchwork erleichtern diesen Prozess erheblich, indem sie Multi-Patch-Beiträge zu einer einzigen Patch-Serie zusammenfassen. Diese Serie läuft als Einheit durch das CKI-System und ermöglicht die Veröffentlichung eines einzelnen Berichts über die Serie.
Andere Trigger überwachen das Repository auf Änderungen. Dies tritt auf, wenn Kernel-Betreuer Patchsets zusammenführen, Patches rückgängig machen oder neue Tags erstellen. Das Testen dieser kritischen Änderungen stellt sicher, dass Entwickler immer über eine solide Basis verfügen, die sie als Grundlage für das Schreiben neuer Patches verwenden können.
Alle diese Änderungen gelangen in eine GitLab-Pipeline und durchlaufen mehrere Phasen und mehrere Systeme.
Vorbereiten des Builds
Alles beginnt damit, den Quellcode für die Kompilierzeit vorzubereiten. Dazu muss das Repository geklont, das vom Entwickler vorgeschlagene Patchset angewendet und eine Kernel-Konfigurationsdatei generiert werden. Diese Konfigurationsdateien haben Tausende von Optionen, die Funktionen ein- oder ausschalten, und Konfigurationsdateien unterscheiden sich unglaublich zwischen verschiedenen Systemarchitekturen. Zum Beispiel kann ein ziemlich standardmäßiges x86_64-System eine Menge Optionen in seiner Konfigurationsdatei haben, aber ein s390x-System (IBM zSeries Mainframes) hat wahrscheinlich viel weniger Optionen. Einige Optionen mögen auf diesem Mainframe sinnvoll sein, aber sie haben keinen Zweck auf einem Consumer-Laptop.
Der Kernel bewegt sich vorwärts und verwandelt sich in ein Quellartefakt. Das Artefakt enthält das gesamte Repository mit angewendeten Patches und allen zum Kompilieren erforderlichen Kernel-Konfigurationsdateien. Upstream-Kernel bewegen sich als Tarball weiter, während Red Hat-Kernel zu einem Quell-RPM für den nächsten Schritt werden.
Stapel von Kompilierungen
Das Kompilieren des Kernels verwandelt den Quellcode in etwas, das ein Computer hochfahren und verwenden kann. Die Konfigurationsdatei beschreibt, was zu bauen ist, Skripte im Kernel beschreiben, wie es gebaut wird, und Tools auf dem System (wie GCC und glibc) erledigen das Bauen. Dieser Vorgang dauert eine Weile, aber das CKI-Projekt muss für vier Architekturen schnell erledigt werden:aarch64 (64-Bit-ARM), ppc64le (POWER), s390x (IBM zSeries) und x86_64. Es ist wichtig, dass wir Kernel schnell kompilieren, damit wir unseren Rückstand überschaubar halten und Entwickler schnelles Feedback erhalten.
Das Hinzufügen weiterer CPUs bietet viele Geschwindigkeitsverbesserungen, aber jedes System hat seine Grenzen. Das CKI-Projekt kompiliert Kernel innerhalb von Containern in einer OpenShift-Bereitstellung; Obwohl OpenShift eine enorme Skalierbarkeit ermöglicht, steht für die Bereitstellung immer noch eine begrenzte Anzahl von CPUs zur Verfügung. Das CKI-Team weist 20 virtuelle CPUs zum Kompilieren jedes Kernels zu. Bei vier beteiligten Architekturen steigt dies auf 80 CPUs!
Eine weitere Geschwindigkeitssteigerung kommt von einem Tool namens ccache. Die Kernel-Entwicklung schreitet schnell voran, aber ein großer Teil des Kernels bleibt auch zwischen mehreren Releases unverändert. Das Ccache-Tool speichert die gebauten Objekte (kleine Teile des gesamten Kernels) während des Kompilierens auf einer Festplatte. Wenn später eine weitere Kernel-Kompilierung kommt, sucht ccache nach unveränderten Teilen des Kernels, die es zuvor gesehen hat. Ccache zieht das zwischengespeicherte Objekt von der Festplatte und verwendet es erneut. Dies ermöglicht schnellere Kompilierungen und eine geringere CPU-Gesamtauslastung. Kernel, deren Kompilierung 20 Minuten gedauert hat, rasen jetzt in weniger als ein paar Minuten zur Ziellinie.
Testzeit
Weitere Linux-Ressourcen
- Spickzettel für Linux-Befehle
- Spickzettel für fortgeschrittene Linux-Befehle
- Kostenloser Online-Kurs:RHEL Technical Overview
- Spickzettel für Linux-Netzwerke
- SELinux-Spickzettel
- Spickzettel für allgemeine Linux-Befehle
- Was sind Linux-Container?
- Unsere neuesten Linux-Artikel
Der Kernel geht zu seinem letzten Schritt über:dem Testen auf echter Hardware. Jeder Kernel bootet mit Beaker auf seiner nativen Architektur, und unzählige Tests beginnen, ihn zu stochern, um Probleme zu finden. Einige Tests suchen nach einfachen Problemen, wie Problemen mit Containern oder Fehlermeldungen beim Booten. Andere Tests tauchen tief in verschiedene Kernel-Subsysteme ein, um Regressionen in Systemaufrufen, Speicherzuweisung und Threading zu finden.
Große Test-Frameworks wie das Linux Test Project (LTP) enthalten Unmengen von Tests, die nach problematischen Regressionen im Kernel suchen. Einige dieser Regressionen könnten kritische Sicherheitskorrekturen rückgängig machen, und es gibt Tests, um sicherzustellen, dass diese Verbesserungen im Kernel verbleiben.
Nach Abschluss der Tests bleibt ein entscheidender Schritt übrig:die Berichterstellung. Kernel-Entwickler und -Betreuer benötigen einen prägnanten Bericht, der ihnen genau sagt, was funktioniert hat, was nicht funktioniert hat und wie sie weitere Informationen erhalten. Jeder CKI-Bericht enthält Details über den verwendeten Quellcode, die Kompilierungsparameter und die Testausgabe. Diese Informationen helfen Entwicklern zu wissen, wo sie mit der Suche nach einem Problem beginnen können. Außerdem hilft es den Betreuern zu wissen, wann ein Patchset für einen weiteren Blick aufbewahrt werden muss, bevor ein Fehler seinen Weg in ihr Kernel-Repository findet.
Zusammenfassung
Das CKI-Projektteam ist bestrebt, das Eindringen von Fehlern in den Linux-Kernel zu verhindern, indem es Kernel-Entwicklern und -Betreuern zeitnahes, automatisiertes Feedback gibt. Diese Arbeit erleichtert ihre Arbeit, indem sie die tief hängenden Früchte findet, die zu Kernel-Fehlern, Sicherheitsproblemen und Leistungsproblemen führen.
Um mehr zu erfahren, können Sie vom 12. bis 13. September im Anschluss an die Linux Plumbers Conference vom 9. bis 11. September in Lissabon, Portugal, am CKI Hackfest teilnehmen.