URL: https://linuxfr.org/news/tuxmake-et-le-noyau-linux Title: TuxMake et le noyau Linux Authors: Rémi Duraffort palm123, Pierre Jarillon, Julien Jorge et Ysabeau Date: 2022-03-08T20:45:33+01:00 License: CC By-SA Tags: linux, compilation, toolchain, testing et ci Score: 5 La compilation du noyau Linux est souvent présentée comme étant triviale : un appel à `make` et c’est réglé. Cependant les choses se compliquent vite si l’on souhaite : * cross-compiler * utiliser différentes toolchains (ou versions) * reproduire une compilation sur une autre machine * utiliser une toolchain non-supportée par sa distribution * … En connaissant bien le fonctionnement de sa distribution et les règles de compilations du noyau Linux, c’est tout à fait faisable même si cela reste fastidieux. D’ailleurs, beaucoup de développeurs du noyau possèdent un jeu de scripts maison pour cela. Afin de rendre cela accessible à tous, Linaro a créé et maintient [TuxMake](https://tuxmake.org). ---- [TuxMake](https://tuxmake.org) [Linaro](https://www.linaro.org/core-technologies/testing-and-ci/) [Podman](https://podman.io/) [LKFT](https://lkft.linaro.org/) [Portable and reproducible kernel builds with TuxMake](https://lwn.net/Articles/841624/) ---- Exemples ======== Grâce à TuxMake, il est maintenant très simple de cross-compiler : ``` git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux/ tuxmake --runtime podman --target-arch=arm64 --toolchain=gcc-10 ``` En une commande, nous venons de cross-compiler mainline avec GCC version 10 pour arm64. Les artefacts de la compilation sont disponibles dans `~/.cache/tuxmake/builds//`. Il est également facile de définir une variable dans la configuration du noyau : ``` tuxmake […] --kconfig-add CONFIG_KVM_GUEST=y ``` Ou encore utiliser un fichier de configuration qui sera ajouté au defconfig : ``` tuxmake […] --kconfig-add https://git.buildroot.net/buildroot/plain/board/qemu/aarch64-sbsa/linux.config ``` En bonus, à la fin de la compilation, TuxMake fournit un ensemble de metadata à propos de la compilation, comme la durée de chaque étape, les tailles des différents binaires, la configuration exacte… ``` cat ~/.cache/tuxmake/builds//metadata.json | jq ``` Une histoire de runtimes ======================== Par défaut, TuxMake utilise les toolchains installés localement. Mais afin de diminuer le nombre de dépendances et de faciliter la reproduction d’une compilation d’une machine à une autre, TuxMake peut utiliser podman (ou docker). Dans ce cas, TuxMake télécharge une image contenant la toolchain sélectionnée et l’utilise pour la compilation. Pour des raisons de sécurité, nous recommandons d’utiliser podman en lieu et place de docker afin d’exécuter les images sans droits root ([rootless containers](https://github.com/containers/podman/blob/main/docs/tutorials/rootless_tutorial.md)). Les images de containers sont créées et maintenues par les développeurs de TuxMake. Celles-ci sont hébergées sur [docker hub](https://hub.docker.com/u/tuxmake) et [ECR](https://gallery.ecr.aws/tuxmake/). Chaque mois, les images sont automatiquement et intégralement recréées afin d’inclure les dernières mises à jour. Toolchains et targets ===================== TuxMake supporte un grand nombre de toolchains : * clang (10, 11, 12, 13, 14, Android, nightly) * gcc (8, 9, 10 et 11) * Rust (clang ou gcc) et d’architectures : * arm et arm64 * i386 et x86_64 * mips, powerpc, riscv, s390, sh, sparc * hexagon, openrisc, parisc, UM ([User Mode Linux](https://fr.wikipedia.org/wiki/User_Mode_Linux)) Évidement toutes les toolchains ne supportent pas toutes les architectures. La matrice de support complète est disponible : ``` tuxmake --runtime podman --print-support-matrix ``` Clang-nightly ------------- Clang-nightly est une toolchain particulière. Contrairement aux autres toolchains, celle-ci est reconstruite chaque jour et inclut la dernière version de clang et LLVM. Ceci permet à l’équipe de [ClangBuiltLinux](https://clangbuiltlinux.github.io/), qui utilise intensivement TuxMake, de valider que clang et LLVM sont à même de compiler le noyau Linux. Une multitude de versions ------------------------- TuxMake fournit des images pour un grand nombre de versions de chaque toolchains : 4 pour GCC et 7 pour clang. Cela est malheureusement nécessaire, car de nombreuses régressions sont trouvés en compilant le noyau linux avec différentes versions de la même toolchain. Reproduire un build =================== Tuxmake est utilisé, via [TuxBuild](https://tuxsuite.com) notre service de compilation dans le cloud, par le projet [LKFT](https://lkft.linaro.org) (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir : * le répertoire git testé * le hash de HEAD * la commande TuxMake Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. Cela semble trivial mais reproduire une erreur de compilation est souvent compliqué car cela peut dépendre d’une version particulière d’une dépendance, par exemple `pahole`. Un exemple parmi tant d’autres : [mips: cavium_octeon_defconfig](https://lore.kernel.org/linux-next/11ec9f44-5e1c-c4cd-8d63-93d7538a12c8@opensource.wdc.com/T/). Et chez moi =========== TuxMake étant un programme Python, il est possible de l’installer depuis [pypi](https://pypi.org/project/tuxmake/) : ``` python3 -m pip install tuxmake ``` Nous fournissons également un paquet [Debian](https://tuxmake.org/install-deb/) et [rpm](https://tuxmake.org/install-rpm/). Présentations ============= Un article très complet a déjà été écrit sur [LWN à propos de TuxMake](https://lwn.net/Articles/841624/). Vous pouvez aussi voir la présentation faite par Antonio Terceiro, le créateur de TuxMake, au [Linaro Virtual Connect 21](https://connect.linaro.org/resources/lvc21/lvc21-106/).