Exemples
TuxRun propose une interface en ligne de commande simple pour exécuter un noyau dans QEMU. TuxRun se charge de fournir un environnement suffisant pour démarrer le noyau avec QEMU.
tuxrun --device qemu-arm64 \
--kernel https://example.com/arm64/Image
TuxRun va alors télécharger le noyau et un système de fichier compatible avec ARM64 puis lancer qemu-system-arm64 avec les bons arguments et afficher les logs du boot.
La ligne de commande de qemu générée par TuxRun est la suivante :
/usr/bin/qemu-system-aarch64 \
-cpu max,pauth-impdef=on \
-machine virt,virtualization=on,gic-version=3,mte=on \
-nographic -nic none -m 4G -monitor none -no-reboot -smp 2 \
-kernel /.../Image \
-append "console=ttyAMA0,115200 rootwait root=/dev/vda debug verbose console_msg_format=syslog systemd.log_level=warning earlycon" \
-drive file=/.../rootfs.ext4,if=none,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0
Il est également possible de lancer une suite de tests directement depuis la ligne de commande :
tuxrun --device qemu-arm64 \
--kernel https://example.com/arm64/Image \
--tests ltp-smoke
Les résultats de la suite de test seront analysés par TuxRun et la valeur de retour de TuxRun sera 0 uniquement si la suite de tests passe intégralement. Ceci permet d’utiliser TuxRun pour valider qu’une suite de tests donnée fonctionne toujours correctement sur un nouveau noyau.
Architectures
QEMU
Grâce à QEMU, TuxRun supporte de nombreuses architectures:
- ARM: v5/v7/v7be/64/64be
- Intel/AMD: i386/x86_64
- MIPS: 32/32el/64/64el
- PPC: 32/64/64le
- RISCV: 32/64
- sh4, sparc64, …
La liste complète est disponible dans la documentation.
FVP
Il est également possible d’utiliser FVP, le simulateur de ARM pour simuler un processeur ARMv9. FVP est un simulateur bien plus précis que QEMU au prix d’un temps d’exécution bien supérieur.
FVP permettant de configurer et simuler de nombreux composants du processeur, TuxRun propose une configuration permettant de démarrer et tester Linux dans un temps raisonnable.
tuxrun --device fvp-aemva \
--kernel https://example.com/arm64/Image \
--tests ltp-smoke \
--image tuxrun:fvp
ARM ne permettant pas (pour le moment) de redistribuer les binaires FVP, il faut construire localement le container tuxrun:fvp.
Système de fichiers
Par défaut, TuxRun télécharge et utilise un système de fichier compatible avec l’architecture cible. TuxRun fournit donc 20 systèmes de fichiers différents, un pour chaque architecture disponible.
Ces systèmes de fichiers sont basés sur buildroot et comportent les outils nécessaires pour faire tourner la majorité des suites de tests supportés par TuxRun. La liste complète est disponible dans la documentation.
Il est également possible d’utiliser un autre système de fichiers :
tuxrun --device qemu-arm64 \
--kernel https://example.com/Image \
--rootfs https://example.com/rootfs.ext4.zst
Runtimes
TuxRun télécharge et utilise un container que nous maintenons. Ce container inclut l’ensemble des binaires nécessaires ainsi que QEMU. Par défaut, TuxRun utilise toujours la dernière version du container disponible.
Il est cependant possible de spécifier une version particulière afin de reproduire plus facilement une erreur. Les nouvelles versions de QEMU introduisent quelques fois des régressions dans les suites de tests. Il est alors nécessaire d’utiliser exactement la même image pour reproduire le problème.
Reproduire un test
TuxRun est utilisé, via tuxsuite notre service de compilation et de test dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir la ligne de commande TuxRun pointant sur les artefacts utilisés pour pouvoir reproduire le problème.
Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. TuxRun simplifie ainsi énormément la reproduction du test.
Un exemple parmi tant d’autres : selftests: sigaltstack: sas…
Installation
TuxRun étant un programme Python, il est possible de l’installer depuis pypi :
python3 -m pip install tuxrun
Nous fournissons également un paquet Debian, et un rpm.
TuxMake et Tuxrun
Dans un prochain article, je vous montrerai comment combiner TuxMake et TuxRun pour automatiquement trouver le commit responsable de la régression dans le noyau.
