La plateforme Linux embarquée fournie par le projet Yocto a la capacité de générer un système embarqué sur Linux adapté aux spécificités d'un projet donné.

En personnalisant les flux de travail et en utilisant les installations existantes pour favoriser la conformité des licences, Yocto peut s'avérer encore plus précieux pour votre distribution personnalisée.

Image 1 : Composantes du projet Yocto et de ses projets en amont

« Il ne s'agit pas d'une distribution Linux embarquée – cela vous en crée une personnalisée » ; voici le titre principal sur le site Web du projet Yocto (https://www.yoctoproject.org/), et il décrit avec précision sa mission : La création d'un système d'exploitation personnalisé sur Linux conçu pour les spécificités d'une carte embarquée et les exigences du futur produit peut s'avérer difficile, mais le projet Yocto a pour mission d'aider. Le projet Yocto, un projet collaboratif en exploitation libre géré par la Fondation Linux, prend en charge plusieurs architectures, notamment x86 (32 et 64 bits), PowerPC, ARM et MIPS. Un nombre croissant de cartes est pris en charge par l'intermédiaire de couches de support de cartes

Pour commencer, intéressons-nous tout d'abord aux composantes principales du projet Yocto. Comme vous pouvez le constater sur l'image 1, le projet Yocto est divisé en plusieurs composantes. Il intègre des parties développées conjointement avec le projet équivalent OpenEmbedded (http://openembedded.org), notamment BitBake, OpenEmbedded-Core et d'autres métadonnées. Les composantes mises au point sous l'égide du projet Yocto, à savoir les « meta-yocto » et les « meta-yocto-bsp », les intégrations Eclipse et d'autres outils, sont inclues. Combinées, elles améliorent les outils du projet OpenEmbedded avec les composantes de Yocto et constituent la plateforme de référence Poky. Grosso modo, Poky est un cadre amélioré pour élaborer des systèmes embarqués sur Linux. Imaginez cela comme un « BuildRoot sous stéroïdes ».

Pour construire un logiciel, une chaîne de compilation (croisée) est nécessaire ; les fichiers sources et les instructions sur la façon de les compiler. C'est suffisant pour une seule source. Mais avec plusieurs composantes et les dépendances liées aux durées de compilation et d'exécution, la complexité augmente et des étapes supplémentaires sont nécessaires. Ces étapes constituent la recette pour le développement du logiciel en question. Des variantes peuvent être créées selon les politiques comme l'architecture cible ou le matériel cible. La conclusion est qu'OpenEmbedded-Core constitue vraiment une collection de recettes ; c'est d'ailleurs l'ensemble de recettes de base. meta-yocto et meta-yocto-bsp sont également des ensembles de recettes, et elles permettent d'améliorer les métadonnées d'OE-Core. Bitbake est désormais à la fois l'analyseur et l'exécuteur des recettes précédemment mentionnées, puis il calcule la chaîne des tâches nécessaires à la construction de la cible définie et l'exécute.

Pour commencer avec Yocto, l'utilisateur doit simplement créer un nouvel environnement de projet et éditer le fichier « conf/local.conf » pour choisir la carte cible par le biais de la variable « MACHINE » avant qu'elle exécute simplement « bitbake » suivie d'une cible comme « bitbake core-image-minimal ». Mais la véritable force du projet Yocto réside dans sa flexibilité à ajouter d'autres recettes, à éditer les recettes existantes et à modifier les politiques en ajoutant des métadonnées dans une soi-disant couche qui repose sur la pile de couches existante (OE-Core + meta-yocto + meta-yocto-bsp). Un exemple d'extension d'un fichier de recette, qui a par convention l'extension « . bb » (p. ex. « hello.bb »), est aussi simple que d'ajouter un fichier portant le même nom et l'extension « . bbappend » (p. ex. « hello.bbappend »). Cela réduit considérablement les travaux d'entretien, étant donné que les intégrateurs de système n'ont qu'à suivre la plus petite modification du fichier .bbappend au lieu d'une copie intégrale. Les mises à jour de maintenance des projets en amont sont donc héritées par la reconstruction de l'image, sans avoir à éditer le moindre fichier de métadonnées. Il s'agit d'un avantage évident, qui justifie les cycles de mémoire supplémentaires nécessaires pour créer de petits fichiers « . bbappend » au lieu d'éditer des copies des recettes originales.

Les recettes sont conservées dans des couches situées dans des sous-dossiers selon chaque thème fonctionnel. Plusieurs couches peuvent être utilisées en même temps. Ce concept est illustré dans l'image 2 ci-dessous ; les couches apportent un support matériel, un support aux applications et même des adaptations locales et elles peuvent être mélangées et assorties au besoin.

Image 2 : Utilisation des couches dans le projet Yocto/Poky

Pour essayer la plateforme de référence « poky » du projet Yocto, vous avez juste besoin d'une machine fonctionnant sous Linux, de 80 Go d'espace libre sur votre disque dur et de suivre ce guide en 5 étapes :

[lancer Box, Police Courier]
# Créez un sous-dossier
mkdir yocto ; yocto CD

# Téléchargez poky :
> wget -O poky.tar.bz2 -nd http://bit.ly/YCpoky
> tar -xf poky.tar.bz2

# créez un nouvel environnement de projet
myproj poky-dizzy-12.0.0/oe-init-build-env source

# la valeur par défaut est qemux86
# comme vous pouvez le constater dans
#  conf/local.conf
# il nous suffit d'exécuter la construction
# - besoin de réseau, de beaucoup d'espace disque
#   et de temps (processeur)

> bitbake core-image-minimal

# la sortie se trouve dans
# tmp/deploy/images
# testez-le avec

> runqemu
[arrêter Box, Police Courier] 

Comme vous allez le constater, la version initiale prend un certain temps, étant donné qu'il lui faut récupérer les sources et tout compiler, y compris les compilateurs croisés/chaîne de compilation. Il est raisonnable de se demander quel serait l'ajustement à travers des groupes de travail ou même par rapport au fait de travailler derrière des pare-feu d'entreprise ? Yocto a répondu à ces questions. L'une des caractéristiques est l'utilisation d'un dossier de téléchargement (DL_DIR dans local.conf), qui est un cache pour les téléchargements et le premier emplacement où bitbake recherche des fichiers sources. Ce rend possible le partage d'un dossier de téléchargement. D'autre part, la fonction PREMIRRORS permet de diriger les téléchargements de la mémoire cache vers une image miroir interne.

L'autre question découlant de l'ajustement est la compilation réelle. Vous avez constaté, ou vous constatez toujours, le temps nécessaire pour télécharger et compiler l'ensemble des éléments pour le core-image-minimal ; faites maintenant le calcul pour un groupe de travail de 10. Pff ! Quel gaspillage de temps de processeur. Yocto peut faire mieux, et nous offre le SSTATE_CACHE. Il s'agit d'un cache pour les résultats de la compilation par environnement cible (combinaison machine + compilateur). Nous pouvons faire pointer les dossiers de projets futurs vers un dossier SSTATE_CACHE existant, puis bitbake viendra chercher les fichiers binaires existants, et la compilation sera considérablement accélérée. Il existe aussi SSTATE_MIRRORS, qui peut être une URL dans le réseau local (p. ex. alimentée par un serveur d'empaquetage automatique ou par intégration continue). Ceci permettrait alors de fournir des fichiers binaires récents à l'ensemble des membres du groupe de travail.

Comme vous pouvez l'imaginer, il s'agit juste la partie visible de l'iceberg en ce qui concerne le niveau de personnalisation rendu possible par le projet Yocto. 

Un autre élément important est d'avoir des informations sur les licences pour les logiciels utilisés dans le système de fichiers, ou même d'exclure les logiciels avec certaines licences. Tout d'abord, chaque logiciel construit avec Yocto doit déclarer sa licence dans la recette. Chaque paquet construit avec Yocto possède un sous-dossier dans le répertoire

<myproj/tmp/deploy/licenses/>. Cela signifie que nous pouvons suivre et vérifier quelles sont les licences utilisées dans le système de fichiers cibles. Par ailleurs, nous pouvons au choix mettre des licences sur liste noire ou sur liste blanche, et par conséquent, exclure ou inclure un logiciel réalisé sous ces licences. La mise sur liste noire est effectuée avec INCOMPATIBLE_LICENSE et la mise sur liste blanche est rendue possible avec LICENSE_FLAGS ou LICENSE_FLAGS_WHITELIST.

Laissez-nous terminer cette introduction avec quelques remarques sur les meilleures pratiques. Un enseignement important est que l'utilisation de l'intégration continue depuis le début s'avère très utile. Cela réduit non seulement le temps de commercialisation et la durée de vie du logiciel réalisé dans le produit, mais cela simplifie également davantage de mises à jour et de mises à niveau. Ceci peut être automatisé, par exemple avec l'installation de gerrit et jenkins. En plus du suivi, le conseil du développement vous permet de travailler directement avec les développeurs en amont du projet Yocto et d'influencer le développement en envoyant des correctifs pour simplifier le prochain cycle de nouvelle version et de mise à jour.

Un dernier mot au sujet des mises à jour : Dans un monde connecté et avec l'essor de l'Internet des objets, nous devons nous soucier de mises à jour rapides et fréquentes. Cela signifie deux choses : a) vous devez être capable de vous adapter et d'importer ces correctifs (souvenez-vous de l'intégration continue ?!) et b) les appareils doivent aller chercher et appliquer les mises à jour. Le projet Yocto peut être configuré pour produire des paquets et paquets RSS de divers formats et tailles (rpm, dpkg, opkg) pour assurer cela.