web-dev-qa-db-fra.com

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 la construction? plans de test?

linuxlinux-kernel
247
Ashkan Kh. Nazary

Le noyau Linux est fortement axé sur les tests de communauté.

Généralement, tout développeur testera son propre code avant de le soumettre, et il utilisera souvent une version de développement du noyau de Linus, ou l’un des autres arbres instables/de développement pour un projet en rapport avec son travail. Cela signifie qu'ils testent souvent leurs modifications et celles des autres.

Il n’ya généralement pas beaucoup de plans de tests formels, mais des tests supplémentaires peuvent être demandés avant la fusion des fonctionnalités dans des arborescences en amont.

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

Les développeurs écriront souvent des tests automatisés pour tester leurs modifications, 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 à modifier, bien entendu. Les tests que vous effectuez pour un nouveau pilote réseau sont très différents de ceux que vous feriez lors du remplacement de l'algorithme de planification principal.

72
JosephH

Naturellement, le noyau lui-même et ses composants ont été testés avant la publication, mais ces tests ne couvrent que les fonctionnalités de base. Il existe certains systèmes de test qui testent le noyau Linux:

Le projet de test Linux (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 un ensemble d’outils permettant de tester le noyau Linux et ses fonctionnalités. 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 de programmes d'espace utilisateur en général sur des plates-formes Linux. Il s'agit d'un projet open-source sous licence GPL. Il est utilisé et développé par un certain nombre d'organisations, notamment 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 versions complètes des distributions GNU/Linux. Il existe des systèmes de certification développés par , Novell, Red Hat, Oracle, Canonical et 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 les éventuelles fuites de mémoire du noyau de la même manière qu'un récupérateur de mémoire de suivi, à la différence que les objets Orphan ne sont pas libérés, mais uniquement signalés via/sys/kernel/debug/kmemleak.

Kmemcheck intercepte chaque lecture et écriture en mémoire allouée dynamiquement (c'est-à-dire avec kmalloc ()). Si une adresse mémoire qui n'a pas encore été écrite est lue, 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.

66
Karen Tsirunyan

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 la construction?

Dans le sens classique des mots, non.

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

Chaque génération échoue, échoue au démarrage, un bogue ou un avertissement d'exécution est traité. 24/7. Multipliez-le par plusieurs cases et vous pourrez découvrir de nombreux problèmes.

plans de test?

Non.

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

56
adobriyan

Outils en ligne

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

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

Noyau CI

https: //kernelci.org/ est un projet qui vise à rendre le test du noyau plus automatisé et visible.

Il semble ne faire que construire et démarrer des tests (TODO comment vérifier automatiquement que le démarrage a fonctionné La source devrait être à https: //github.com/kernelci/ ).

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

Linaro Lava

http: //www.linaro.org/initiatives/lava/ ressemble à un système d'infrastructure de confiance axé sur le développement de la carte de développement et du 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 Licensed, ce qui mérite probablement un coup d’œil.

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

Débogueurs d'étape

Pas vraiment de tests unitaires, mais peut vous aider une fois que vos tests commencent à échouer:

Mon propre QEMU + Buildroot + Python

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

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

15
Ciro Santilli 新疆改造中心996ICU六四事件

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

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 retourner dans le BIOS. S'il échoue, redémarrez.
  • dmesg: C'est certainement l'endroit où chercher des informations sur ce qui s'est passé pendant le démarrage du noyau et savoir 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 de l'ordre de la microseconde) le moment de la sortie du noyau), la configuration du noyau vous permet d'activer BEAUCOUP de traceurs qui leur permettent de déboguer ce qui se passe.

Ensuite, les développeurs demandent généralement aux autres utilisateurs de vérifier leurs correctifs. Une fois que les correctifs sont examinés localement et que rien ne les gêne, 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 vidéo de Nice détaillant le processus suivi par un correctif avant son intégration dans le noyau.

13
Vanwaril

Outre les points ci-dessus/ci-dessous, l'accent est mis davantage sur les tests de fonctionnalité, les tests de certification du matériel et les tests de performance du noyau Linux.

De nombreux tests sont en fait effectués à l'aide de scripts, d'outils d'analyse de code statique, de révision de code, etc., ce qui est très efficace pour détecter les bogues, ce qui autrement casserait quelque chose dans l'application.

Sparse - Outil à code source ouvert conçu pour rechercher les erreurs dans le noyau Linux.

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

checkpatch.pl et autres scripts - Des problèmes de style de codage sont disponibles dans le fichier Documentation/CodingStyle de l’arborescence du noyau. La chose importante à retenir lors de la lecture n'est pas que ce style est meilleur que tout autre style, mais qu'il est cohérent. Cela aide les développeurs à trouver et à résoudre facilement les problèmes de style de code. Le script scripts/checkpatch.pl de l’arborescence du noyau a été développé. Ce script peut signaler des problèmes facilement et doit toujours être exécuté par un développeur sur ses modifications, au lieu de laisser un relecteur perdre son temps en signalant les problèmes ultérieurement.

6
askb

Il y a aussi:

MMTests qui est une collection de points de repère et de scripts pour analyser les résultats

https://github.com/gormanm/mmtests

Trinité qui est testeur de fuzz appel système Linux

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

Également LTP les pages de sourceforge sont relativement obsolètes et le projet est passé à GitHub https://github.com/linux-test-project/ltp

3
metan

J'imagine qu'ils utilisent la virtualisation pour effectuer des tests rapides, tels que QEMU, VirtualBox ou Xen, ainsi que des 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 traitent 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 à partir du noyau, alors j'imagine que c'est également utilisé.

2
emcee

Autant que je sache, il existe un outil de vérification automatique de la régression des performances (nommé lkp/0 day) utilisé/financé par Intel, il testera chaque correctif valide envoyé à la liste de diffusion et vérifiera les scores modifiés à partir de différents microbencheurs tels que hackbench. , fio, unixbench, netperf, etc., une fois que les performances ont été régressées/améliorées, un rapport correspondant sera envoyé directement à l’auteur du correctif et aux mainteneurs liés au Cc.

1
Yu Chen

J'avais fait la compilation du noyau linux et quelques modifications pour Android (Marshmallow et Nougat) dans lesquelles j'utilisais Linux version 3. Je l'ai compilé dans le système linux, déboguer les erreurs manuellement, puis exécuter son fichier image de démarrage dans Android et vérifiez s’il fonctionnait ou non. Si tout fonctionne parfaitement, cela signifie qu’il est parfaitement compilé conformément à la configuration système requise.
Pour la compilation du noyau MotoG

NOTE: - Le noyau Linux changera en fonction des besoins qui dépendent du matériel système.

0
Vineet Jain

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

0
Pradeep Goswami

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

L'idée derrière cette configuration est d'avertir les développeurs le plus tôt possible afin qu'ils puissent corriger les erreurs assez rapidement. (avant que les correctifs ne soient intégrés à l'arbre de Linus dans certains cas, l'infrastructure de kbuild testant également les arbres de sous-système du responsable)

0
krisharav