Comment le noyau Linux est-il testé?

le noyau linux met fortement l'accent sur les tests communautaires.

en général, tout développeur teste son propre code avant de le soumettre, et très souvent il utilise une version de développement du noyau de Linus, ou l'une des autres arborescences unstable/development pour un projet pertinent à son travail. Cela signifie qu'ils testent souvent à la fois leurs changements et ceux des autres.

il n'y a généralement pas beaucoup de test formel plans, mais des tests supplémentaires peuvent être demandés avant de fusionner les caractéristiques dans les arbres en amont.

comme Dean l'a souligné, il y a aussi des tests automatisés, le linux test project et le kernel autotest ( good overview ).

les développeurs vont souvent aussi écrire des tests automatisés destinés à tester leur changement, mais je ne suis pas sûr qu'il y ait un (souvent utilisé) mécanisme de collecte centralisée ces adhoc tests.

cela dépend beaucoup de la zone du noyau qui est changée bien sûr - le test que vous feriez pour un nouveau pilote réseau est très différent du test que vous feriez en remplaçant l'algorithme de programmation du noyau.

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

Linux Projet de Test (LTP) offre des suites de test pour la communauté open source qui permettent de valider la fiabilité et la stabilité de Linux. La suite de tests LTP contient une collection d'outils pour tester le noyau Linux et ses fonctionnalités. https://github.com/linux-test-project/ltp

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

il y a aussi des systèmes de certification développés par certaines grandes entreprises 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 pour analyse du noyau Linux:

Kmemleak est un détecteur de fuites 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 collecteur de déchets de traçage avec la différence que les objets orphelins ne sont pas libérés mais seulement signalés via /sys/kernel/debug/kmemleak.

Kmemcheck piège chaque lecture et écriture à la mémoire qui a été attribuée dynamiquement (i.e. avec kmalloc()). Si une adresse mémoire n'a pas encore été écrite, 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'introduire des erreurs et des exceptions dans la logique d'une application pour obtenir une couverture plus élevée et une plus grande tolérance de défauts du système.

comment les développeurs du noyau Linux testent-ils leur code localement et une fois qu'ils l'ont engagé?

utilisent-ils une sorte de test d'unité, l'automatisation de la compilation?

Dans le sens classique de mots, pas de.

E. G. Ingo Molnar exécute la charge de travail suivante:: 1. construire un nouveau noyau avec un ensemble d'options de configuration 2. démarrage en elle 3. goto 1

Chaque échec, échec de démarrage, L'avertissement de bogue ou d'exécution est traité. 24/7. Multipliez par plusieurs boîtes, et on peut découvrir pas mal de problèmes.

plans d'essai?

Pas de.

il peut y avoir un malentendu sur le fait qu'il y a une installation centrale d'essai, il n'y en a pas. Chacun fait ce qu'il veut.

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

cependant, il y a quelques choses qui aident à déboguer le noyau Linux:

• kexec: un appel système qui vous permet de mettre un autre noyau en mémoire et de redémarrer sans retourner au BIOS, et s'il échoue, redémarrez.
• dmesg: certainement l'endroit pour 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 une option appelée "CONFIG_PRINTK_TIME" qui vous permet de voir (avec une précision de microseconde) quand le noyau affiche quoi), la configuration du noyau vous permet d'activer de nombreux traceurs qui leur permettent de déboguer ce qui se passe.

alors, les développeurs ont généralement d'autres revues de leurs patches. Une fois que les correctifs sont passés en revue localement et ne semblent pas interférer avec quoi que ce soit d'autre, et que les correctifs sont testés pour fonctionner avec le dernier noyau de Linus sans casser quoi que ce soit, les correctifs sont poussés en amont.

Edit: Voici une belle vidéo détaillant le processus qu'un patch passe avant d'être intégré dans le noyau.

Dans l'arborescence des outils

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

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

In v4.0, ce qui m'amène à:

• kselftest sous outils/test/selftests . Exécutez avec make kselftest . Doit être en cours d'exécution construit noyau déjà. Voir aussi: Documentation / kselftest.txt , https://kselftest.wiki.kernel.org/

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

• analyseurs statiques section de make help , qui contient des cibles comme:

  • checkstack : Perl: ce qui fait checkstack.pl dans linux source do?
  • coccicheck pour Coccinelle (mentionné par askb )

Noyau CI

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

il semble ne faire que les tests de construction et de démarrage (TODO comment tester automatiquement que boot worked Source devrait être à https://github.com/kernelci / ).

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

Linaro De Lave

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

ARM LISA

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

Je ne suis pas sûr de ce qu'il fait en détail, mais il est par ARM et Apache autorisé, donc probablement la peine d'un coup d'oeil.

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

Étape débogueurs

pas vraiment de test unitaire, mais peut aider une fois que vos tests commencent à échouer:

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

en plus des points ci-dessus / ci-dessous, qui mettent l'accent sur le test de fonctionnalité, le test de certification du matériel et le test de performance du noyau Linux.

beaucoup d'essais se passent dans la réalité à travers, en fait des scripts, des outils d'analyse de code statique, revues de code, etc. ce qui est très efficace pour détecter les bogues qui, autrement, briseraient 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 fait moteur de correspondance et de transformation qui fournit le langage SmPL (Semantic Patch Language) pour spécifier les correspondances et les transformations désirées dans le code C.

checkpatch.pl et d'Autres scripts - les problèmes de style de codage peuvent être trouvés dans le fichier Documentation/CodingStyle dans l'arbre des sources du noyau. La chose importante à retenir en le lisant, ce n'est pas que ce style soit en quelque sorte meilleur que n'importe quel autre style, juste qu'il soit cohérent. cela permet aux développeurs de trouver et de corriger facilement les problèmes de style de codage, le script scripts/checkpatch.pl dans l'arbre des sources du noyau a été développé. Ce script peut facilement pointer des problèmes, et devrait toujours être exécuté par un développeur sur leurs modifications, au lieu de faire perdre leur temps à un examinateur en pointant des problèmes plus tard.

il y a aussi:

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

https://github.com/gormanm/mmtests

Trinité qui est appel système Linux fuzz testeur

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

aussi le LTP pages à la sourceforge sont tout à fait périmés et le projet a déménagé à GitHub https://github.com/linux-test-project/ltp

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.

test automatisé est probablement fait en essayant soit beaucoup de configurations aléatoires ou quelques unes spécifiques (si elles travaillent avec un problème spécifique). Linux a beaucoup d'outils de bas niveau (comme dmesg) pour surveiller et consigner les données de débogage du noyau, donc j'imagine que c'est aussi bien utilisé.

autant que je sache, il y a un outil automatique de vérification de régression de performance(nommé lkp/0 jour) fonctionnant/financé par Intel, il va tester chaque patch valide envoyé à la liste de diffusion et vérifier les scores changés à partir de microbenchmarks différents tels que hackbench, fio, unixbench, netperf, etc, une fois qu'il y a une régression/amélioration de performance, un rapport correspondant sera envoyé directement à l'auteur du patch et les mainteneurs liés au Cc.

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

adobriyan a mentionné la boucle D'Ingo de test de construction de configuration aléatoire. C'est à peu près maintenant couvert par le 0-day test bot (alias kbuild test bot). Un bel article à propos de l'infrastructure est présenté ici: Noyau/boot test

l'idée derrière cette configuration est de notifier les développeurs dès que possible afin qu'ils puissent rectifier les erreurs assez rapidement. (avant que les patches le fassent dans L'arbre de Linus dans certains cas comme l'infrastructure kbuild aussi essais par rapport aux arbres du sous-système de maintenance)

j'avais fait la compilation du noyau linux et fait quelques Modifications pour android(Marshmallow et Nougat) dans lequel j'utilise la version 3 de linux. Je l'ai compilé dans le système linux, déboguer les erreurs manuellement, puis lancer son fichier image de démarrage dans Android et vérifier si elle allait dans Boucle-trou ou non. S'il fonctionne parfaitement, cela signifie qu'il est parfaitement compilé selon les exigences du système.

Pour MotoG la Compilation d'un noyau

NOTE: - le noyau Linux va changer selon les exigences qui dépendent du matériel du système