TuxRun et le noyau Linux

Posté par  (site web personnel) . Édité par palm123, Benoît Sibaud, Xavier Teyssier et Arkem. Modéré par Xavier Teyssier. Licence CC By‑SA.
Étiquettes :
37
27
mar.
2024
Linux

Il y a quelques années, je vous avais présenté TuxMake, un utilitaire pour faciliter la (cross-)compilation du noyau Linux supportant une grande variété de toolchains différentes : TuxMake et le noyau Linux.

TuxMake facilitant la compilation du noyau Linux, nous nous sommes alors attaqués à rendre l’exécution de ces noyaux plus aisée : ainsi est né TuxRun.

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.

Aller plus loin

  • # Ouahhh

    Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

    Je suis impressionné par ces outils !

    Est-ce que c’est utilisé par les mainteneurs du noyau Linux ? Si oui, dans quelle mesure ? Si non, pourquoi, que manque-t-il ?

    • [^] # Re: Ouahhh

      Posté par  . Évalué à 2 (+0/-0).

      Oui, ça à l'air de déchirer! Un simple "pertinent" ne me suffisait pas, même si ce commentaire n'ajoute rien. Je tiens à préciser qu'en général, je me méfie des trucs en python (ne pas chercher de raison a un truc subjectif, merci), mais ici, l'intérêt me semble largement dépasser mon habituelle résistance (au changement?).

      • [^] # Re: Ouahhh

        Posté par  (site web personnel) . Évalué à 5 (+4/-0).

        TuxMake et TuxRun étant globalement des wrapper autour d'outils déjà existant (make, qemu, fvp, LAVA, …) utiliser python permet de développer assez rapidement et fournis beaucoup de fonctions pour écrire un wrapper (subprocess par exemple).

    • [^] # Re: Ouahhh

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      Oui TuxMake est utilisé par de plus en plus de mainteneurs du noyau principalement du fait que les rapports de bugs qui sont remontés par Linaro sont basés sur TuxMake.

      L'adoption est lente car les développeurs on chacun des scripts maison qui correspondent à leur cas d'usage. Ce n'est donc pas forcément pertinent de changer tant que le cas d'usage n'évolue pas. Les bugs un peu difficile à reproduire (du fait de la toolchain principalement) sont souvent une bonne occasion de tester TuxMake.

      TuxRun étant un outils beaucoup plus récent, l'adoption est beaucoup plus faible même si nous savons que quelques mainteneurs l'utilise déjà. L'adoption de TuxRun devrait probablement suivre la même courbe que celle de TuxMake mais avec un certain décalage.

      Il est aussi difficile de savoir qui utilise TuxMake/TuxRun car les mainteneurs mentionne rarement publiquement (du fait de la publicité qui en découle) les outils qu'ils utilisent.

  • # Un autre Docker?

    Posté par  . Évalué à 1 (+0/-0).

    Ne pourrait-on pas utiliser TuxRun comme un docker étendu? Je veux dire docker permet d'isoler un programme mais quand on veut en avoir plusieurs il faut plusieurs docker avec un docker-compose et la communication inter-docker est compliquer.
    TuxRun est plus lourd/lent car il lance une véritable VM mais il permet de lancer un os complet avec tout ce qu'on veut y mettre. Si c'est bien packagé ça peut-être plus simple que de lancer une "vrai" VM ou de risquer de pourrir son PC…

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.