Dans Tests d'intégration continue pour le noyau Linux , J'ai écrit sur le projet d'intégration continue du noyau (CKI) et sa mission de changer la façon dont les développeurs et les mainteneurs du noyau travaillent. Cet article est une plongée en profondeur dans certains des aspects les plus techniques du projet et comment toutes les pièces s'emboîtent.
Tout commence par un changement
Chaque fonctionnalité passionnante, amélioration et bogue dans le noyau commence par un changement proposé par un développeur. Ces modifications apparaissent sur une myriade de listes de diffusion pour différents référentiels du noyau. Certains référentiels se concentrent sur certains sous-systèmes du noyau, tels que le stockage ou la mise en réseau, tandis que d'autres se concentrent sur des aspects généraux du noyau. Le projet CKI entre en action lorsque les développeurs proposent une modification, ou un ensemble de correctifs, au noyau ou lorsqu'un responsable apporte des modifications au référentiel lui-même.
Le projet CKI maintient des déclencheurs qui surveillent ces ensembles de correctifs et prennent des mesures. Les projets logiciels tels que Patchwork facilitent grandement ce processus en rassemblant les contributions de plusieurs correctifs en une seule série de correctifs. Cette série voyage en tant qu'unité dans le système CKI et permet de publier un seul rapport sur la série.
D'autres déclencheurs surveillent le référentiel pour les modifications. Cela se produit lorsque les responsables du noyau fusionnent des ensembles de correctifs, annulent des correctifs ou créent de nouvelles balises. Le test de ces modifications critiques garantit que les développeurs disposent toujours d'une base de référence solide à utiliser comme base pour l'écriture de nouveaux correctifs.
Tous ces changements se retrouvent dans un pipeline GitLab et passent par plusieurs étapes et plusieurs systèmes.
Préparer le build
Tout commence par préparer la source pour le moment de la compilation. Cela nécessite de cloner le référentiel, d'appliquer le patchset proposé par le développeur et de générer un fichier de configuration du noyau. Ces fichiers de configuration ont des milliers d'options qui activent ou désactivent des fonctionnalités, et les fichiers de configuration diffèrent incroyablement entre les différentes architectures système. Par exemple, un système x86_64 assez standard peut avoir une tonne d'options disponibles dans son fichier de configuration, mais un système s390x (mainframes IBM zSeries) a probablement beaucoup moins d'options. Certaines options peuvent avoir un sens sur ce mainframe, mais elles n'ont aucune utilité sur un ordinateur portable grand public.
Le noyau avance et se transforme en un artefact source. L'artefact contient l'intégralité du référentiel, avec les correctifs appliqués, et tous les fichiers de configuration du noyau nécessaires à la compilation. Les noyaux en amont se déplacent comme une archive tar, tandis que les noyaux Red Hat deviennent un RPM source pour l'étape suivante.
Piles de compilations
La compilation du noyau transforme le code source en quelque chose qu'un ordinateur peut démarrer et utiliser. Le fichier de configuration décrit ce qu'il faut construire, les scripts du noyau décrivent comment le construire et les outils du système (comme GCC et glibc) font la construction. Ce processus prend un certain temps, mais le projet CKI en a besoin pour quatre architectures :aarch64 (ARM 64 bits), ppc64le (POWER), s390x (IBM zSeries) et x86_64. Il est important que nous compilions les noyaux rapidement afin que nous gardions notre backlog gérable et que les développeurs reçoivent des commentaires rapides.
L'ajout de processeurs supplémentaires offre de nombreuses améliorations de la vitesse, mais chaque système a ses limites. Le projet CKI compile les noyaux dans des conteneurs dans un déploiement OpenShift ; bien qu'OpenShift permette des tonnes d'évolutivité, le déploiement dispose toujours d'un nombre fini de processeurs disponibles. L'équipe CKI alloue 20 processeurs virtuels pour compiler chaque noyau. Avec quatre architectures impliquées, cela grimpe à 80 processeurs !
Une autre augmentation de la vitesse provient d'un outil appelé ccache. Le développement du noyau évolue rapidement, mais une grande partie du noyau reste inchangée même entre plusieurs versions. L'outil ccache met en cache les objets construits (petits morceaux du noyau global) pendant la compilation sur un disque. Lorsqu'une autre compilation du noyau arrive plus tard, ccache recherche les parties inchangées du noyau qu'il a vues auparavant. Ccache extrait l'objet mis en cache du disque et le réutilise. Cela permet des compilations plus rapides et une utilisation globale réduite du processeur. Les noyaux qui ont pris 20 minutes à compiler se précipitent maintenant vers la ligne d'arrivée en moins de quelques minutes.
Temps de test
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
Le noyau passe à sa dernière étape :tester sur du matériel réel. Chaque noyau démarre sur son architecture native à l'aide de Beaker, et une myriade de tests commencent à le pousser pour trouver des problèmes. Certains tests recherchent des problèmes simples, tels que des problèmes avec les conteneurs ou des messages d'erreur au démarrage. D'autres tests plongent profondément dans divers sous-systèmes du noyau pour trouver des régressions dans les appels système, l'allocation de mémoire et le threading.
Les grands frameworks de test, tels que Linux Test Project (LTP), contiennent des tonnes de tests qui recherchent des régressions gênantes dans le noyau. Certaines de ces régressions pourraient annuler des correctifs de sécurité critiques, et il existe des tests pour s'assurer que ces améliorations restent dans le noyau.
Une étape critique reste à la fin des tests :le reporting. Les développeurs et les mainteneurs du noyau ont besoin d'un rapport concis qui leur indique exactement ce qui a fonctionné, ce qui n'a pas fonctionné et comment obtenir plus d'informations. Chaque rapport CKI contient des détails sur le code source utilisé, les paramètres de compilation et la sortie de test. Ces informations aident les développeurs à savoir par où commencer pour résoudre un problème. De plus, cela aide les mainteneurs à savoir quand un ensemble de correctifs doit être conservé pour un autre examen avant qu'un bogue ne se retrouve dans leur référentiel du noyau.
Résumé
L'équipe du projet CKI s'efforce d'empêcher les bogues d'entrer dans le noyau Linux en fournissant des commentaires automatisés et opportuns aux développeurs et aux responsables du noyau. Ce travail facilite leur travail en trouvant les fruits à portée de main qui entraînent des bogues du noyau, des problèmes de sécurité et des problèmes de performances.
Pour en savoir plus, vous pouvez assister au CKI Hackfest les 12 et 13 septembre après la Linux Plumbers Conference du 9 au 11 septembre à Lisbonne, au Portugal.