Comment le noyau Linux est-il testé?

Comment les développeurs du noyau Linux testent-ils leur code localement et après l'avoir validé? Utilisent-ils une sorte de test unitaire, d'automatisation de construction? plans de test?

Le noyau Linux met fortement l'accent sur les tests de communauté.

En règle générale, tout développeur testera son propre code avant de le soumettre, et très souvent, il utilisera une version de développement du noyau de Linus, ou l'un des autres arbres instables / de développement pour un projet pertinent pour son travail. Cela signifie qu'ils testent souvent leurs changements et ceux des autres.

Il n'y a généralement pas beaucoup de plans de test formels, mais des tests supplémentaires peuvent être demandés avant que les fonctionnalités ne soient fusionnées dans les arbres en amont.

Comme l'a souligné Dean, il existe également des tests automatisés, le projet de test Linux et l' autotest du noyau ( bonne vue d'ensemble ).

Les développeurs écrivent également souvent des tests automatisés destinés à tester leur modification, mais je ne suis pas sûr qu'il existe un mécanisme (souvent utilisé) pour collecter de manière centralisée ces tests ad hoc.

Cela dépend beaucoup de la zone du noyau qui est modifiée bien sûr - les tests que vous feriez pour un nouveau pilote réseau sont très différents de ceux que vous feriez lors du remplacement de l'algorithme de planification de base.

Naturellement, le noyau lui-même et ses composants sont testés avant la sortie, mais ces tests ne couvrent que les fonctionnalités de base. Il existe des systèmes de test qui effectuent des tests du noyau Linux:

Le Linux Test Project (LTP) fournit des suites de tests à la communauté open source qui valident la fiabilité et la stabilité de Linux. La suite de tests LTP contient une collection d'outils pour tester le noyau Linux et les fonctionnalités associées. https://github.com/linux-test-project/ltp

Autotest - un cadre pour des tests entièrement automatisés. Il est principalement conçu pour tester le noyau Linux, bien qu'il soit utile à de nombreuses autres fins telles que la qualification de nouveau matériel, les tests de virtualisation et d'autres tests généraux de programme d'espace utilisateur sous les plates-formes Linux. Il s'agit d'un projet open source sous GPL et est utilisé et développé par un certain nombre d'organisations, dont Google, IBM, Red Hat et bien d'autres. http://autotest.github.io/

Il existe également des systèmes de certification développés par certaines grandes sociétés de distribution GNU / Linux. Ces systèmes vérifient généralement la compatibilité des distributions GNU / Linux complètes avec le matériel. Il existe des systèmes de certification développés par Novell, Red Hat, Oracle, Canonical, Google .

Il existe également des systèmes d'analyse dynamique du noyau Linux:

Kmemleak est un détecteur de fuite de mémoire inclus dans le noyau Linux. Il fournit un moyen de détecter d'éventuelles fuites de mémoire du noyau d'une manière similaire à un récupérateur de place de traçage à la différence que les objets orphelins ne sont pas libérés mais uniquement signalés via / sys / kernel / debug / kmemleak.

Kmemcheck intercepte chaque lecture et écriture dans la mémoire allouée dynamiquement (c'est-à-dire avec kmalloc ()). Si une adresse mémoire n'a pas été écrite auparavant, un message est imprimé dans le journal du noyau. Fait également partie du noyau Linux

Fault Injection Framework (inclus dans le noyau Linux) permet d'infuser des erreurs et des exceptions dans la logique d'une application pour obtenir une couverture et une tolérance aux pannes plus élevées du système.

Comment les développeurs du noyau Linux testent-ils leur code localement et après l'avoir validé?

Utilisent-ils une sorte de test unitaire, d'automatisation de construction?

Dans le sens classique des mots, non.

Par exemple. Ingo Molnar exécute la charge de travail suivante: 1. construire un nouveau noyau avec un ensemble aléatoire d'options de configuration 2. démarrer dedans 3. goto 1

Chaque échec de build, échec de démarrage, BUG ou avertissement d'exécution est traité. 24/7. Multipliez par plusieurs cases, et on peut découvrir pas mal de problèmes.

plans de test?

Non.

Il peut y avoir un malentendu sur le fait qu'il existe une installation de test centrale, il n'y en a pas. Chacun fait ce qu'il veut.

Outils dans l'arborescence

Un bon moyen de trouver des outils de test dans le noyau est de:

• make help et lire toutes les cibles
• regardez sous outils / tests

En v4.0, cela m'amène à:

• kselftest sous tools / testing / selftests . Courez avec make kselftest. Doit déjà exécuter le noyau construit. Voir aussi: Documentation / kselftest.txt , https://kselftest.wiki.kernel.org/

• ktest sous tools / testing / ktest . Voir aussi: http://elinux.org/Ktest , http://www.slideshare.net/satorutakeuchi18/kernel-auto-testbyktest

• Section Analyseurs statiques de make help, qui contient des cibles telles que:

  • checkstack: Perl: que fait checkstack.pl dans la source linux?
  • coccicheckpour Coccinelle (mentionné par askb )

Kernel CI

https://kernelci.org/ est un projet qui vise à rendre les tests du noyau plus automatisés et visibles.

Il semble ne faire que des tests de construction et de démarrage (TODO comment tester automatiquement le démarrage de la source devrait être sur https://github.com/kernelci/ ).

Linaro semble être le principal responsable du projet, avec des contributions de nombreuses grandes entreprises: https://kernelci.org/sponsors/

Linaro Lava

http://www.linaro.org/initiatives/lava/ ressemble à un système CI avec un focus sur le développement de la carte de développement et le noyau Linux.

ARM LISA

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

Je ne sais pas ce qu'il fait en détail, mais c'est par ARM et Apache sous licence, donc ça vaut probablement le coup d'oeil.

Démo: https://www.youtube.com/watch?v=yXZzzUEngiU

Débogueurs d'étape

Pas vraiment des tests unitaires, mais cela peut aider une fois que vos tests ont échoué:

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

Ma propre configuration QEMU + Buildroot + Python

J'ai également commencé une configuration axée sur la facilité de développement, mais j'ai également ajouté quelques fonctionnalités de test simples: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/8217e5508782827320209644dcbaf9a6b3141724#test-this -repo

Je n'ai pas analysé toutes les autres configurations en détail, et elles font probablement beaucoup plus que la mienne, mais je pense que ma configuration est très facile à démarrer rapidement car elle a beaucoup de documentation et d'automatisation.

Ce n'est pas très facile d'automatiser les tests du noyau. La plupart des développeurs Linux effectuent les tests par eux-mêmes, un peu comme adobriyan l'a mentionné.

Cependant, il y a quelques choses qui aident au débogage du noyau Linux:

• kexec: Un appel système qui vous permet de mettre un autre noyau en mémoire et de redémarrer sans revenir au BIOS, et s'il échoue, redémarrez.
• dmesg: Certainement l'endroit où chercher des informations sur ce qui s'est passé pendant le démarrage du noyau et si cela fonctionne / ne fonctionne pas.
• Instrumentation du noyau: en plus de printk (et d'une option appelée 'CONFIG_PRINTK_TIME' qui vous permet de voir (avec une précision en microsecondes) quand le noyau produit quoi), la configuration du noyau vous permet d'activer BEAUCOUP de traceurs qui leur permettent de déboguer ce est passe.

Ensuite, les développeurs demandent généralement à d'autres de revoir leurs correctifs. Une fois que les correctifs sont examinés localement et ne semblent interférer avec rien d'autre, et que les correctifs sont testés pour fonctionner avec le dernier noyau de Linus sans rien casser, les correctifs sont poussés en amont.

Edit: Voici une belle vidéo détaillant le processus par lequel un correctif passe avant qu'il ne soit intégré au noyau.

En plus des points ci-dessus / ci-dessous, qui mettent davantage l'accent sur les tests de fonctionnalité, les tests de certification matérielle et les tests de performances du noyau Linux.

De nombreux tests se produisent réellement, en fait des scripts, des outils d'analyse de code statique, des revues de code, etc., ce qui est très efficace pour détecter les bogues, ce qui autrement casserait quelque chose dans l'application.

Sparse - Un outil open-source conçu pour trouver des défauts dans le noyau Linux.

Coccinelle est un autre programme de moteur de correspondance et de transformation qui fournit le langage SmPL (Semantic Patch Language) pour spécifier les correspondances et les transformations souhaitées dans le code C.

checkpatch.pl et d'autres scripts - les problèmes de style de codage se trouvent dans le fichier Documentation / CodingStyle de l'arborescence des sources du noyau. La chose importante à retenir lors de la lecture n'est pas que ce style est en quelque sorte meilleur que tout autre style, mais simplement qu'il est cohérent. cela aide les développeurs à trouver et à résoudre facilement les problèmes de style de codage, le script scripts / checkpatch.pl dans l'arborescence des sources du noyau a été développé. Ce script peut signaler les problèmes facilement et doit toujours être exécuté par un développeur sur leurs modifications, au lieu de laisser un réviseur perdre son temps en signalant les problèmes plus tard.

J'imagine qu'ils utilisent la virtualisation pour faire des tests rapides, quelque chose comme QEMU, VirtualBox ou Xen, et certains scripts pour effectuer des configurations et des tests automatisés.

Les tests automatisés sont probablement effectués en essayant de nombreuses configurations aléatoires ou quelques configurations spécifiques (si elles fonctionnent avec un problème spécifique). Linux a beaucoup d'outils de bas niveau (tels que dmesg) pour surveiller et enregistrer les données de débogage du noyau, donc j'imagine que cela est également utilisé.

Il y a aussi:

MMTests qui est une collection de benchmarks et de scripts pour analyser les résultats

https://github.com/gormanm/mmtests

Trinity qui est un testeur de fuzz d'appels système Linux

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

De plus, les pages LTP de la sourceforge sont assez obsolètes et le projet est passé à GitHub https://github.com/linux-test-project/ltp

Pour autant que je sache, il existe un outil de vérification de régression des performances (nommé lkp / 0 day) exécuté / financé par Intel, il testera chaque correctif valide envoyé à la liste de diffusion et vérifiera les scores modifiés à partir de différents microbenchmarks tels que hackbench , fio, unixbench, netperf, etc., une fois qu'il y a une régression / amélioration des performances, un rapport correspondant sera envoyé directement à l'auteur du patch et aux mainteneurs liés à Cc.

LTP et Memtests sont généralement des outils préférés.

adobriyan a mentionné la boucle d'Ingo de tests de construction de config aléatoires. C'est à peu près maintenant couvert par le bot de test de 0 jour (alias bot de test kbuild). Un bel article sur l'infrastructure est présenté ici: Kernel Build / boot testing

L'idée derrière cette configuration est d'informer les développeurs dès que possible afin qu'ils puissent corriger les erreurs assez rapidement. (avant que les correctifs ne se transforment en arborescence de Linus dans certains cas, car l'infrastructure kbuild teste également par rapport aux arborescences du sous-système du responsable)

J'avais fait la compilation du noyau linux et fait quelques modifications pour Android (Marshmallow et Nougat) dans lesquelles j'utilise la version 3. de Linux. ça allait en boucle ou pas. S'il fonctionne parfaitement, cela signifie qu'il est parfaitement compilé selon les exigences du système.
Pour la compilation du noyau MotoG

REMARQUE: - Le noyau Linux changera en fonction des exigences qui dépendent du matériel système

Une fois que les contributeurs ont soumis leurs fichiers de correctifs et après avoir fait une demande de fusion, les portiers Linux vérifient le correctif en l'intégrant et en le révisant. Le projet de test Linux ( https://github.com/linux-test-project/ltp ) est la principale source qui fournit des scénarios de test (cas de test) à exécuter sur le noyau après l'application de correctifs. Cela peut prendre environ 2 à 4 heures et dépend. Veuillez noter que le système de fichiers du noyau sélectionné va être testé. Ex: Ext4 génère des résultats différents contre EXT3 et ainsi de suite.

Procédure de test du noyau.

1. Obtenez la dernière source du noyau à partir du référentiel ( https://www.kernel.org/ ou Github.com)
2. Appliquer le fichier de patch (à l'aide de l'outil Diff)
3. Construisez un nouveau noyau.
4. Test par rapport aux procédures de test dans LTP ( https://github.com/linux-test-project/ltp )