Wie wird der Linux-Kernel getestet?

Wie testen die Linux-Kernel-Entwickler ihren Code lokal und nachdem sie ihn festgeschrieben haben? Verwenden sie eine Art Unit-Test, Build-Automatisierung? Testpläne?

Der Linux-Kernel legt großen Wert auf Community-Tests.

In der Regel testet jeder Entwickler seinen eigenen Code, bevor er ihn sendet, und verwendet häufig eine Entwicklungsversion des Kernels von Linus oder einen der anderen instabilen / Entwicklungsbäume für ein für seine Arbeit relevantes Projekt. Dies bedeutet, dass sie häufig sowohl ihre Änderungen als auch die Änderungen anderer Personen testen.

Es gibt in der Regel nicht viel in Bezug auf formale Testpläne, aber es können zusätzliche Tests erforderlich sein, bevor Features zu vorgelagerten Bäumen zusammengeführt werden.

Wie Dean betonte, gibt es auch einige automatisierte Tests, das Linux-Testprojekt und den Kernel-Autotest ( guter Überblick ).

Entwickler schreiben häufig auch automatisierte Tests, um ihre Änderungen zu testen, aber ich bin mir nicht sicher, ob es einen (häufig verwendeten) Mechanismus gibt, um diese Ad-hoc-Tests zentral zu erfassen.

Es hängt natürlich stark davon ab, welcher Bereich des Kernels geändert wird. Die Tests, die Sie für einen neuen Netzwerktreiber durchführen würden, unterscheiden sich erheblich von den Tests, die Sie beim Ersetzen des zentralen Planungsalgorithmus durchführen würden.

Natürlich werden der Kernel selbst und seine Teile vor der Veröffentlichung getestet, aber diese Tests decken nur die Grundfunktionalität ab. Es gibt einige Testsysteme, die Tests des Linux-Kernels durchführen:

Das Linux Test Project (LTP) stellt der Open Source-Community Testsuiten zur Verfügung, die die Zuverlässigkeit und Stabilität von Linux überprüfen. Die LTP-Testsuite enthält eine Sammlung von Tools zum Testen des Linux-Kernels und verwandter Funktionen. https://github.com/linux-test-project/ltp

Autotest - ein Framework für vollautomatische Tests. Es wurde hauptsächlich zum Testen des Linux-Kernels entwickelt, obwohl es für viele andere Zwecke nützlich ist, z. B. zum Qualifizieren neuer Hardware, zum Testen der Virtualisierung und für andere allgemeine Tests von User Space-Programmen unter Linux-Plattformen. Es ist ein Open-Source-Projekt unter der GPL und wird von einer Reihe von Organisationen verwendet und entwickelt, darunter Google, IBM, Red Hat und viele andere. http://autotest.github.io/

Es gibt auch Zertifizierungssysteme, die von einigen großen GNU / Linux-Vertriebsunternehmen entwickelt wurden. Diese Systeme überprüfen normalerweise vollständige GNU / Linux-Distributionen auf Kompatibilität mit Hardware. Es gibt Zertifizierungssysteme, die von Novell, Red Hat, Oracle, Canonical und Google entwickelt wurden .

Es gibt auch Systeme zur dynamischen Analyse des Linux-Kernels:

Kmemleak ist ein Speicherleckdetektor, der im Linux-Kernel enthalten ist. Es bietet eine Möglichkeit, mögliche Kernel-Speicherlecks ähnlich wie bei einem Tracing-Garbage-Collector zu erkennen, mit dem Unterschied, dass die verwaisten Objekte nicht freigegeben, sondern nur über / sys / kernel / debug / kmemleak gemeldet werden.

Kmemcheck fängt jedes Lesen und Schreiben in den Speicher ein, der dynamisch zugewiesen wurde (dh mit kmalloc ()). Wenn eine Speicheradresse gelesen wird, in die zuvor noch nicht geschrieben wurde, wird eine Nachricht in das Kernelprotokoll gedruckt. Ist auch ein Teil des Linux-Kernels

Das Fault Injection Framework (im Linux-Kernel enthalten) ermöglicht das Einfügen von Fehlern und Ausnahmen in die Logik einer Anwendung, um eine höhere Abdeckung und Fehlertoleranz des Systems zu erreichen.

Wie testen die Linux-Kernel-Entwickler ihren Code lokal und nachdem sie ihn festgeschrieben haben?

Verwenden sie eine Art Unit-Test, Build-Automatisierung?

Im klassischen Sinne der Worte, nein.

Z.B. Ingo Molnar führt die folgende Arbeitslast aus: 1. Erstellen Sie einen neuen Kernel mit zufälligen Konfigurationsoptionen. 2. Starten Sie ihn. 3. Gehen Sie zu 1

Jeder Build-Fehler, Boot-Fehler, BUG oder Laufzeitwarnung wird behandelt. 24/7. Multiplizieren Sie mit mehreren Kästchen, und Sie können eine ganze Reihe von Problemen aufdecken.

Testpläne?

Nein.

Es kann ein Missverständnis geben, dass es eine zentrale Testeinrichtung gibt, es gibt keine. Jeder macht was er will.

In-Tree-Tools

Ein guter Weg, um Testwerkzeuge im Kernel zu finden, ist:

• make help und lesen Sie alle Ziele
• Schauen Sie unter Werkzeuge / Tests

In v4.0 führt mich dies zu:

• Selbsttest unter Werkzeuge / Tests / Selbsttests . Laufen Sie mit make kselftest. Muss bereits einen erstellten Kernel ausführen. Siehe auch: Documentation / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest unter tools / testing / ktest . Siehe auch: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• Statische Analysatoren Abschnitt von make help, der Ziele enthält wie:

  • checkstack: Perl: Was macht checkstack.pl in Linux Source?
  • coccicheckfür Coccinelle (erwähnt von askb )

Kernel CI

https://kernelci.org/ ist ein Projekt, das darauf abzielt, Kerneltests automatisierter und sichtbarer zu machen.

Es scheint nur Build- und Boot-Tests durchzuführen (TODO, wie automatisch getestet wird, ob der Boot funktioniert hat, sollte sich unter https://github.com/kernelci/ befinden ).

Linaro scheint der Hauptbetreuer des Projekts zu sein, mit Beiträgen vieler großer Unternehmen: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/initiatives/lava/ sieht aus wie ein CI-System, das sich auf die Entwicklung von Entwicklungsplatinen und den Linux-Kernel konzentriert.

ARM LISA

https://github.com/ARM-software/lisa

Ich bin mir nicht sicher, was es im Detail macht, aber es ist von ARM und Apache Licensed, also wahrscheinlich einen Blick wert.

Demo: https://www.youtube.com/watch?v=yXZzzUEngiU

Schritt Debugger

Nicht wirklich Unit-Tests, kann aber hilfreich sein, wenn Ihre Tests fehlschlagen:

• QEMU + GDB: https://stackoverflow.com/a/42316607/895245
• KGDB: https://stackoverflow.com/a/44226360/895245

Mein eigenes QEMU + Buildroot + Python-Setup

Ich habe auch ein Setup gestartet, das sich auf die einfache Entwicklung konzentriert, aber am Ende habe ich auch einige einfache Testfunktionen hinzugefügt: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

Ich habe nicht alle anderen Setups detailliert analysiert, und sie leisten wahrscheinlich viel mehr als meine, aber ich glaube, dass mein Setup sehr einfach ist, schnell zu beginnen, da es viel Dokumentation und Automatisierung enthält.

Es ist nicht sehr einfach, Kerneltests zu automatisieren. Die meisten Linux-Entwickler führen die Tests selbst durch, ähnlich wie Adobriyan erwähnt.

Es gibt jedoch einige Dinge, die beim Debuggen des Linux-Kernels helfen:

• kexec: Ein Systemaufruf, mit dem Sie einen anderen Kernel in den Speicher stellen und neu starten können, ohne zum BIOS zurückzukehren. Wenn dies fehlschlägt, starten Sie den Computer neu .
• dmesg: Auf jeden Fall der Ort, an dem nach Informationen gesucht werden kann, was während des Kernel- Starts passiert ist und ob es funktioniert / nicht funktioniert.
• Kernel-Instrumentierung: Zusätzlich zu printks (und einer Option namens 'CONFIG_PRINTK_TIME', mit der Sie (mit Mikrosekundengenauigkeit) sehen können, wann der Kernel was ausgibt) können Sie in der Kernel-Konfiguration eine Vielzahl von Tracern aktivieren, mit denen sie was debuggen können es passiert.

Dann lassen Entwickler normalerweise andere ihre Patches überprüfen. Sobald die Patches lokal überprüft wurden und festgestellt wurden, dass sie nichts anderes stören, und die Patches getestet wurden, um mit dem neuesten Kernel von Linus zu arbeiten, ohne etwas zu beschädigen, werden die Patches nach oben verschoben.

Bearbeiten: Hier ist ein schönes Video, das den Prozess beschreibt, den ein Patch durchläuft, bevor er in den Kernel integriert wird.

Zusätzlich zu den obigen / unteren Punkten, die sich mehr auf das Testen der Funktionalität, das Testen der Hardwarezertifizierung und das Testen der Leistung des Linux-Kernels konzentrieren.

Tatsächlich werden viele Tests durchgeführt, und zwar durch Skripte, Tools zur statischen Code-Analyse, Codeüberprüfungen usw., was sehr effizient ist, um Fehler zu erkennen, die sonst etwas in der Anwendung beschädigen würden.

Sparse - Ein Open-Source-Tool zum Auffinden von Fehlern im Linux-Kernel.

Coccinelle ist ein weiteres Programm zur Matching- und Transformations-Engine, das die Sprache SmPL (Semantic Patch Language) zur Angabe gewünschter Übereinstimmungen und Transformationen in C-Code bereitstellt.

checkpatch.pl und andere Skripte - Probleme mit dem Codierungsstil finden Sie in der Datei Documentation / CodingStyle im Kernel-Quellbaum. Das Wichtigste beim Lesen ist nicht, dass dieser Stil irgendwie besser ist als jeder andere Stil, sondern dass er konsistent ist. Dies hilft Entwicklern, Probleme mit dem Codierungsstil leicht zu finden und zu beheben. Das Skript scripts / checkpatch.pl im Kernel-Quellbaum wurde entwickelt. Dieses Skript kann Probleme leicht aufzeigen und sollte immer von einem Entwickler bei seinen Änderungen ausgeführt werden, anstatt dass ein Prüfer seine Zeit damit verschwendet, später auf Probleme hinzuweisen.

Ich würde mir vorstellen, dass sie Virtualisierung verwenden, um schnelle Tests durchzuführen, etwa QEMU, VirtualBox oder Xen, und einige Skripte, um Konfigurationen und automatisierte Tests durchzuführen.

Automatisierte Tests werden wahrscheinlich durchgeführt, indem entweder viele zufällige oder einige bestimmte Konfigurationen ausprobiert werden (wenn sie mit einem bestimmten Problem arbeiten). Linux verfügt über viele einfache Tools (wie z. B. dmesg) zum Überwachen und Protokollieren von Debug-Daten aus dem Kernel. Ich kann mir also vorstellen, dass dies auch verwendet wird.

Es gibt auch:

MMTests ist eine Sammlung von Benchmarks und Skripten zur Analyse der Ergebnisse

https://github.com/gormanm/mmtests

Trinity ist ein Linux-System-Call-Fuzz-Tester

http://codemonkey.org.uk/projects/trinity/

Auch die LTP- Seiten in der Quellform sind ziemlich veraltet und das Projekt wurde auf GitHub https://github.com/linux-test-project/ltp verschoben

Soweit ich weiß, gibt es ein Tool zur automatischen Überprüfung der Leistungsregression (mit dem Namen lkp / 0 Tag), das von Intel ausgeführt / finanziert wird. Es testet jeden gültigen Patch, der an die Mailingliste gesendet wird, und überprüft die von verschiedenen Mikrobenchmarks wie Hackbench geänderten Ergebnisse , fio, unixbench, netperf usw. Sobald eine Leistungsregression / -verbesserung vorliegt, wird ein entsprechender Bericht direkt an den Patch-Autor und die Cc-bezogenen Betreuer gesendet.

LTP und Memtests sind im Allgemeinen bevorzugte Tools.

Adobriyan erwähnte Ingos Schleife von zufälligen Konfigurations-Build-Tests. Das wird jetzt so ziemlich vom 0-Tage-Testbot (auch bekannt als kbuild-Testbot) abgedeckt. Ein schöner Artikel über die Infrastruktur wird hier vorgestellt: Kernel Build / Boot-Test

Die Idee hinter dieser Einrichtung ist es, die Entwickler so schnell wie möglich zu benachrichtigen, damit sie die Fehler früh genug beheben können. (bevor die Patches in einigen Fällen in den Linus-Baum gelangen, da die kbuild-Infrastruktur auch anhand der Subsystembäume des Betreuers testet)

Ich hatte die Linux-Kernel-Kompilierung durchgeführt und einige Modifikationen für Android (Marshmallow und Nougat) vorgenommen, in denen ich Linux Version 3 verwende. Ich habe es im Linux-System überkompiliert, die Fehler manuell debuggt und dann die Boot-Image-Datei in Android ausgeführt und überprüft, ob es ging in eine Lücke oder nicht. Wenn es perfekt läuft, bedeutet dies, dass es perfekt gemäß den Systemanforderungen kompiliert wurde.
Für die MotoG-Kernel-Kompilierung

HINWEIS: - Der Linux-Kernel ändert sich entsprechend den Anforderungen, die von der Systemhardware abhängen

Sobald die Mitwirkenden ihre Patch-Dateien eingereicht haben und nachdem sie eine Zusammenführungsanforderung gestellt haben, überprüfen Linux-Gatekeeper den Patch, indem sie ihn integrieren und überprüfen. Sobald dies erfolgreich ist, werden sie den Patch in den entsprechenden Zweig zusammenführen und eine neue Version veröffentlichen. Linux-Testprojekt ( https://github.com/linux-test-project/ltp ) ist die Hauptquelle, die Testszenarien (Testfälle) bereitstellt, die nach dem Anwenden von Patches gegen den Kernel ausgeführt werden können. Dies kann ca. 2 ~ 4 Stunden dauern und hängt davon ab. Bitte beachten Sie, dass das Dateisystem des ausgewählten Kernels getestet werden soll. Beispiel: Ext4 generiert unterschiedliche Ergebnisse für EXT3 usw.

Kernel-Testverfahren.

1. Holen Sie sich die neueste Kernelquelle aus dem Repository ( https://www.kernel.org/). Kernelquelle oder Github.com).
2. Patch-Datei anwenden (mit Diff-Tool)
3. Erstellen Sie einen neuen Kernel.
4. Test gegen Testverfahren in LTP ( https://github.com/linux-test-project/ltp )