Vous n’aurez probablement pas besoin de Yocto, et ce n’est pas grave

• Yocto n’est pas une distribution, mais un ensemble d’outils pour assembler sa propre distribution Linux, et il est difficile d’en faire le choix par défaut si l’on n’a pas besoin d’un tel niveau de contrôle
• Une distribution maison signifie maintenance maison, avec en plus les contraintes réglementaires comme le CRA et la responsabilité de fournir des mises à jour de sécurité pendant toute la durée de vie du produit
• Adopter Yocto implique des builds de plusieurs heures, des répertoires de build dépassant les 100 Gio, une courbe d’apprentissage de plusieurs semaines et des couches BSP de qualité très variable
• Si l’on a simplement besoin d’une base Linux robuste pour exécuter une application, Debian et des outils d’image comme mkosi, ELBE ou debos peuvent largement suffire avec bien moins de travail spécifique au projet
• Yocto ne l’emporte que lorsqu’il faut une forte personnalisation, des contraintes strictes de taille ou de temps de démarrage, des exclusions de licence, ainsi qu’un support Yocto fournisseur solide ; en cas de doute, une distribution existante est préférable

---

Ce qu’est réellement Yocto, et pourquoi il devient souvent le choix par défaut

• Yocto n’est pas une « distribution Yocto Linux », mais un ensemble d’outils permettant de créer sa propre distribution Linux
• Le projet Yocto fournit aussi Poky, une distribution de référence construite avec bitbake, openembedded-core et meta-yocto
• Yocto permet d’assembler très finement le système Linux nécessaire à un projet embarqué
  • il est possible de compiler l’ensemble de l’espace utilisateur pour le CPU cible
  • des correctifs peuvent être appliqués à n’importe quel composant
  • les fonctionnalités de chaque recette peuvent être activées ou désactivées
  • toutes les versions peuvent être figées ou modifiées
• De nombreux fournisseurs de SoC et partenaires matériels proposent des couches BSP (Board Support Package) prêtes à l’emploi, offrant un point de départ fonctionnel sur le vrai matériel
• C’est cette combinaison de flexibilité et de support fournisseur qui fait de Yocto un choix par défaut, mais si l’on n’a pas besoin d’autant de contrôle, la charge peut devenir supérieure au bénéfice

Une distribution maison signifie une maintenance maison

• Des réglementations comme le Cyber Resilience Act (CRA) imposent au fournisseur du produit de maintenir la sécurité du logiciel qu’il distribue et de fournir des mises à jour de sécurité pendant toute la durée de vie du produit
• Une version Yocto classique n’est maintenue qu’environ 7 mois, jusqu’à la sortie de la version suivante
• À partir de Yocto 5.0 Scarthgap, les versions LTS reçoivent selon la politique actuelle des mises à jour pendant jusqu’à 4 ans
• Une version Yocto se compose d’un ensemble de recettes bitbake avec des versions et métadonnées données, ainsi que de la distribution de référence Poky
• Pendant la période de maintenance, les mainteneurs de Yocto appliquent des corrections de bugs et de sécurité aux composants et à Poky, les corrections des composants logiciels étant généralement rétroportées depuis les versions upstream les plus récentes
• Dans un produit réel, il est fréquent de ne pas utiliser Yocto tel quel, mais d’y apporter des modifications comme :
  • l’application de correctifs non triviaux ou de changements locaux sur certains composants
  • l’ajout de composants supplémentaires non fournis par Yocto
  • des mises à niveau ou gels de version afin de recevoir des correctifs ou de conserver un état connu comme bon
• À chaque version de maintenance Yocto, il faut vérifier que les changements locaux se réappliquent proprement sur le nouvel état
• Les composants ajoutés ou figés ne sont pas connus des mainteneurs de Yocto ; il faut donc aussi vérifier soi-même qu’ils continuent à recevoir des correctifs
• Si Poky est utilisé presque sans modification, il faut reconsidérer la raison d’utiliser Yocto

Noyau Linux et dépendance au fournisseur

• Yocto fournit et maintient un noyau Linux dans chaque version, mais dans un produit réel il est rare qu’il soit utilisé sans modification
• En pratique, il faut au minimum appliquer des correctifs du fournisseur et utiliser un noyau suffisamment récent contenant les pilotes et corrections nécessaires
• Avec le suivi des CVE, le noyau représente à lui seul une charge de maintenance importante, que l’on utilise Yocto ou non
• Pour maîtriser cette charge, il est recommandé de construire sur un noyau LTS de kernel.org et de conserver toutes les modifications dans une file de correctifs propre
• Pour suivre les correctifs de sécurité, on passe aux nouvelles versions stables puis on réapplique la file de correctifs
• Comme kernel.org maintient les noyaux LTS pendant plusieurs années, la file de correctifs s’applique en général proprement, et un vrai travail n’est nécessaire qu’au passage à une nouvelle version LTS
• Selon la configuration et les exigences de sécurité, les mêmes principes s’appliquent au bootloader, lui aussi généralement très spécifique au fournisseur
• Conserver tel quel le noyau fourni par le vendeur est généralement une mauvaise idée
  • le noyau fournisseur a souvent plusieurs années de retard sur kernel.org
  • il reçoit très peu de mises à jour
  • il rate la plupart des correctifs de sécurité

Le coût d’adoption de Yocto

• Le choix de créer sa propre distribution exige un véritable temps d’ingénierie

• Temps de build

  • Yocto compile pratiquement tout depuis les sources
  • même un build propre d’une image un peu plus que triviale prend plusieurs heures sur une station de travail rapide
  • sstate-cache et un DL_DIR partagé accélèrent les builds répétés, mais une petite modification d’une recette peut suffire à invalider une grande partie du cache

• Coût disque et CI

  • un répertoire de build Yocto peut facilement dépasser 100 Gio
  • les runners CI doivent disposer d’assez de stockage et d’un mécanisme de partage de sstate entre les tâches
  • le mirroring de sstate et de DL_DIR réduit la douleur, mais il faut exploiter cette infrastructure soi-même

• Courbe d’apprentissage

  • il faut assimiler les recettes bitbake, les couches, les couches dynamiques, les classes, les overrides, les fichiers bbappend, PACKAGECONFIG, la différence entre DEPENDS et RDEPENDS, etc.
  • l’onboarding d’un ingénieur sur la base de code Yocto prend non pas quelques jours, mais plusieurs semaines

• Variation de qualité des couches BSP

  • certains fournisseurs de SoC proposent des couches BSP propres et bien maintenues
  • d’autres livrent des couches meta-vendor qui figent un noyau ou un bootloader vieux de 5 ans, codent en dur des recettes spécifiques à la machine dans la mauvaise couche et cassent à chaque montée de version de Poky
  • un BSP qui semble être un bon point de départ peut devenir la pire partie du build
  • ce ne sont pas des raisons d’éviter Yocto à tout prix, mais des raisons de vérifier en amont si l’on en a réellement besoin

Alternative : réutiliser une distribution éprouvée

• Si l’on a seulement besoin d’une base Linux robuste pour exécuter une application, une distribution existante comme Debian GNU/Linux résout une grande partie des mêmes problèmes avec beaucoup moins de travail spécifique au projet
• Debian fournit actuellement environ 70 000 paquets binaires
• Les architectures prises en charge incluent amd64, i386, arm64, armhf, riscv64, ppc64el, entre autres
• Beaucoup de SoC peuvent probablement exécuter directement des binaires Debian sans recompilation
• Debian n’est pas seulement une distribution fournissant un espace utilisateur moderne avec systemd, udev et dbus
• L’archive contient aussi de quoi construire de petits systèmes Linux basés sur une init de style SysV ou sur BusyBox
• On peut choisir une base légère et n’installer que les paquets nécessaires au produit, tout en profitant du travail des mainteneurs de paquets Debian

Le modèle de maintenance de Debian

• Debian stable reçoit des mises à jour de sécurité de l’équipe Debian Security pendant environ 3 ans
• Ensuite, le projet communautaire Debian LTS prolonge le support d’environ 2 ans supplémentaires sur les architectures courantes
• En pratique, cela donne environ 5 ans de support par version, soit un niveau comparable à Yocto LTS, mais avec beaucoup moins de travail spécifique au projet
• Pour obtenir les derniers correctifs, il suffit de prendre les paquets Debian à jour et de reconstruire l’image
• La nature du travail est très différente de celle qui consiste, avec Yocto, à rétroporter soi-même des correctifs upstream ou à revérifier que les changements locaux continuent à s’appliquer sur les versions de maintenance

Comment sont construites les images embarquées

• Une image embarquée basée sur Debian ne consiste pas à démarrer le SoC sur une clé USB puis à lancer l’installateur Debian
• Elle consiste à générer sur l’hôte de build une image flashable, puis à l’écrire sur l’appareil
• Les éléments nécessaires sont les suivants
  • un bootloader généralement spécifique au SoC, par exemple u-boot
  • un noyau Linux généralement spécifique au SoC
  • un système de fichiers racine basé sur l’espace utilisateur Linux, pris directement depuis Debian
  • un outil d’assemblage d’image combinant ces trois éléments en une image flashable
• Les choix courants d’outils d’assemblage d’image sont mkosi, ELBE, debos
• Ces trois outils sont des logiciels libres et produisent des images déterministes pouvant être flashées sur le matériel
• Le travail de maintenance diminue fortement, et la plupart des mises à jour consistent surtout à rafraîchir les paquets de l’image à la manière d’apt, plutôt qu’à réécrire des recettes

Exemple de build Debian avec debos

• debos lit des recettes YAML
• Une recette est composée d’une liste d’actions, comme exécuter des commandes, créer un système de fichiers racine ou installer des paquets Debian depuis des sources configurées
• Le flux de base est le suivant
  • exploiter un miroir Debian local avec aptly contenant une copie de tous les paquets Debian nécessaires
  • construire le noyau Linux, et si nécessaire le bootloader, sous forme de paquets Debian puis les ajouter au miroir
  • créer un snapshot du miroir et lui attribuer un tag
  • ce tag devient la version publiée
  • configurer debos pour utiliser ce miroir et écrire les actions de recette qui fabriquent l’image cible
  • si nécessaire, conserver avec l’image les paquets source Debian ainsi que son SBOM (Software Bill of Materials)
• Conserver les paquets source et le SBOM aide à respecter les obligations de fourniture du code source imposées par la GPL ainsi que les exigences de nomenclature du CRA
• Des outils comme debsbom génèrent un SBOM directement à partir d’un système Debian

Quand choisir Yocto

• Yocto est adapté lorsqu’il faut une distribution fortement personnalisée
  • espace utilisateur personnalisé
  • options de compilation personnalisées
  • modifications profondes des composants de base
• Il convient lorsqu’il existe des contraintes strictes de taille ou de temps de démarrage impossibles à satisfaire avec une distribution prête à l’emploi
• Il convient aussi en présence de contraintes de licence imposant d’exclure certaines catégories de licences
  • dans certains secteurs comme les dispositifs médicaux, l’automobile ou certains travaux de défense, on ne distribue pas de composants GPLv3
  • le mécanisme INCOMPATIBLE_LICENSE de Yocto facilite l’exclusion de familles de licences sur l’ensemble de l’image
  • avec une base Debian classique, il faut auditer et réduire soi-même les paquets
• Il convient lorsque la voie de support officielle du fournisseur de SoC est Yocto et que la qualité du BSP est solide

Quand éviter Yocto

• Si l’on a seulement besoin d’un Linux moderne pour y déployer et exécuter une application, Yocto n’est peut-être pas nécessaire
• Si le budget de stockage et de mémoire peut absorber une image Debian classique, l’avantage de Yocto diminue
  • l’ordre de grandeur donné en exemple est de plusieurs centaines de Mo de flash et de 256 Mo de RAM ou plus
• Si la durée de vie du produit est longue et qu’il vaut mieux s’appuyer sur Debian Security Team que sur une maintenance interne, il est judicieux d’éviter Yocto

Quand éviter Debian

• Si l’on doit modifier ou reconstruire beaucoup de paquets Debian, Debian devient moins adapté
  • reconstruire quelques paquets reste gérable
  • chaque paquet reconstruit devient une charge de maintenance que l’on porte soi-même
  • corriger des dizaines de paquets upstream revient à refaire le travail normalement assuré par les mainteneurs Debian
  • à cette échelle, le modèle par recettes de Yocto gère cela plus proprement
• Si l’on a besoin d’une libc non glibc comme musl ou uClibc, Debian n’est pas le bon choix
  • l’archive principale de Debian repose globalement sur glibc
  • la remplacer impose de reconstruire soi-même l’essentiel de l’archive
• Si l’on a besoin de logiciels bien plus récents que ceux fournis par Debian stable, Debian devient moins adapté
  • les backports peuvent aider pour certains paquets
  • si le produit exige un compilateur récent ou un runtime récent, cela entre en conflit avec Debian stable
  • Debian testing n’est pas une cible de production

Principes de décision et conclusion

• Le choix d’utiliser Yocto doit être fait en conscience, dès le début du produit
• C’est un choix de fondation qu’il est difficile d’inverser une fois le produit déployé sur le terrain
• En cas de doute, mieux vaut partir d’une distribution existante
• Le coût d’un passage ultérieur vers Yocto, lorsqu’une vraie raison apparaît, est bien inférieur au fait de découvrir en cours de projet que l’on s’est imposé pendant des années une charge de maintenance sans bénéfice concret
• Yocto est une réalisation d’ingénierie remarquable, capable de produire exactement le système Linux dont on a besoin, mais c’est précisément ce niveau de contrôle qui devient un problème quand il n’est pas nécessaire
• La même logique s’applique presque telle quelle à d’autres outils de build à partir des sources comme Buildroot
• Dès que l’on assemble sa propre distribution, on assume aussi directement la responsabilité de sa maintenance
• La conclusion essentielle est claire
  • une « distribution maison » signifie en réalité maintenance maison
  • le CRA et les réglementations similaires transforment ce coût en contrainte bien réelle
  • un build Yocto fortement modifié n’hérite pas gratuitement des correctifs upstream
  • chaque version de maintenance devient un travail de revue et de reprise
  • une distribution existante comme Debian, mise en image avec mkosi, ELBE ou debos, couvre les cas généraux avec bien moins d’effort spécifique au projet
  • lorsque l’on a besoin d’un contrôle chirurgical du système, Yocto l’emporte
  • sinon, choisir Yocto revient à résoudre longuement et à grands frais un problème qui n’existe pas

[GN⁺]

Avis sur Lobste.rs

• Si la voie de support officielle du fournisseur de SoC est Yocto, même si le BSP n’est pas très solide, ça reste en général préférable à un portage Ubuntu de mauvaise qualité
  Les portages Ubuntu rendent pénibles des tâches comme l’intégration de RAUC ou l’immuabilité du système de fichiers racine. Je déteste vraiment Yocto et ses dialectes bash/python dérivés, mais au final on reste coincé avec

• Je fais beaucoup de conseil autour de Yocto, mais je n’ai presque jamais rencontré les problèmes dont l’article se lamente. En général, c’est plutôt l’inverse : même quand Yocto est la meilleure option, les clients essaient malgré tout de l’éviter, et il faut convaincre la direction
  Cela dit, je comprends que Yocto soit détesté. C’est difficile, déroutant, lent, et les outils pourraient être meilleurs. Je ne sais pas vraiment s’il existe une alternative sérieuse, et je me demande s’il y a quelque chose de similaire côté BSD

  • Je ne sais pas à quel point c’est proche de Yocto, mais la manière classique de créer des images de systèmes embarqués sous FreeBSD est NanoBSD
    https://docs.freebsd.org/en/articles/nanobsd/
  • Je ne l’ai pas utilisé en profondeur en production, et c’est peut-être moins abouti que Yocto, mais buildroot contient pas mal de choses intéressantes
    Je l’ai surtout utilisé dans le contexte de Nerves, qui est essentiellement une combinaison de buildroot + fwup + VM Erlang et logiciels de support. C’était assez pratique pour développer, packager et déployer des systèmes Linux embarqués
  • Je ne travaille pas directement sur des systèmes Linux/BSD embarqués, mais pour avoir utilisé NetBSD, le système de build build.sh semble déjà largement suffisant
    Il permet de cross-compiler facilement le noyau et l’espace utilisateur. À la fin, si on doit ajouter des applications pkgsrc ou inclure un bootloader comme u-boot dans l’image générée, il faut peut-être un peu de scripting. Ce n’est peut-être pas un flux complet directement personnalisable pour une application, mais comme base c’est correct
  • NetBSD est conçu pour faciliter la cross-compilation vers des environnements contraints, et une fois qu’on a pris le coup de main, c’est plutôt agréable

• D’après ma faible expérience, après avoir un peu goûté à l’horreur de l’embarqué, NixOS convenait plutôt bien à ce genre d’usage, et les outils de build étaient bien meilleurs que ceux de Yocto

  • Je me demande si c’est aussi vrai sur des appareils ARM. J’avais l’impression que l’écosystème NixOS était encore un peu en avance sur ce type de matériel

• Justement, on a commencé à planifier et construire au travail un noyau Linux personnalisé et une distribution pour des appareils basés sur Rockchip, donc l’article tombe à pic
  Le BSP semble demander pas mal de maintenance, et utiliser Debian “tel quel” paraît bien plus gérable que les tâches bitbake que j’ai bricolées n’importe comment. Cela dit, l’écosystème Yocto lui-même est plutôt bon, et il existe des outils comme kas ou isar qui facilitent le démarrage

  • En lisant le README d’isar, on dirait que ce n’est pas Yocto mais basé sur Debian. Je me demande s’il est courant de mélanger les deux
    L’article semble parler de Yocto ou Debian, pas d’une approche qui combinerait les deux