Logiciels Libres et Systèmes Embarqués


A.2. Système de base

A.2.1. Système CoreUtils

A.2.1.1. Présentation

CoreUtils est un ensemble d'utilitaires indispensables à tout système d'exploitation de type GNU. On retrouve typiquement des commandes telles que ls, mv, cp, ... Toutes les distributions Linux pour station de travail se basent sur les CoreUtils.

A.2.1.2. Installation

L'installation des CoreUtils est des plus simples :

bash# CC=powerpc-405-linux-gnu-gcc      \
      ./configure --host=i686           \
                  --disable-nls         \
                  --prefix=$SYSROOT
bash# make
bash# make install
bash# cp $SYSROOT/bin /mnt/ramdisk/bin

CC=

précise le compilateur à utiliser. Comme nous faisons de la compilation croisée, nous indiquons le compilateur pour notre cible.

--host=i686

précise le type de l'hôte. Cette option est indispensable lorsque l'on fait de la compilation croisée.

--disable-nls

désactive le "Native Language Support", il s'agit des traductions des CoreUtils. Etant donné qu'on travaille dans le domaine de l'embarqué, cette fonctionnalité n'a que peu d'intérêt, de plus le sur-coût en taille engendré par les tables de traduction est beaucoup trop important (4.7 Mo).

--prefix

précise où seront installés les CoreUtils. Lors de l'installation, trois répertoires seront créés : /bin, /info et /man.

A.2.1.3. Evaluation

Le tableau suivant présente les résultats obtenus lors de la compilation des CoreUtils avec différentes bibliothèques C compatibles (la valeur entre parenthèses indique la taille prise par celles-ci) :

Tableau A.1. Evaluation de CoreUtils

CoreUtils 5.2.1nombre de commandesavec GlibC 2.3.5avec µClibC 0.9.27
en statique8945468 Ko6104 Ko
en dynamique894888 Ko (2156 Ko)2932 Ko (328 Ko)


Comme nous pouvons le constater, un système à base de CoreUtils pourrait faire près de 3 Mo. A première vue, cela pourrait sembler petit, mais il ne faut pas oublier qu'il manque encore l'interpréteur de commande [26]. Sachant qu'il existe des alternatives bien plus petites, nous pouvons considérer que les CoreUtils ne sont pas viables dans le domaine de l'embarqué.

A.2.2. BusyBox

A.2.2.1. Evaluation

Le tableau suivant présente les résultats obtenus lors de la compilation de BusyBox avec différentes bibliothèques C compatibles :

Tableau A.2. Evaluation de BusyBox

BusyBox 1.0.0nombre de commandesavec GlibC 2.3.5avec µClibC 0.9.27
en dynamique par défaut981684 Ko (1396 Ko) 598 Ko (276 Ko)
en statique par défaut98908 Ko388 Ko
en dynamique complet2052952 Ko (2124 Ko)1164 Ko (328 Ko)
en statique complet2051880 Ko996 Ko


On pourrait être étonné de voir que la version statique soit plus petite que la version dynamique (munie de ses bibliothèques). Cela vient du fait que tous les utilitaires de BusyBox sont inclus dans un même binaire, et partage donc toutes les fonctions de base, il n'y a alors aucune redondance. Etant donné que dans la version statique seules les fonction utilisées sont intégrées au binaire, la version dynamique est pénalisée par le poids de toutes les autres fonctions disponibles dans la bibliothèque C. Mais il faut faire très attention à l'interprétation de ces résultats car ils ne sont pas parlants. En effet, si on reproduit ce test en rajoutant d'autres programmes (indépendant de BusyBox), le système dynamique sera bien plus petit que le système statique équivalent.

Comme nous pouvons le constater, un système à base de BusyBox pourrait faire entre 400 Ko et 1 Mo, tout dépend du nombre de commandes et du niveau de fonctionnalités que l'on souhaite. Il serait même possible de faire un système encore plus petit si on configure BusyBox correctement, la taille minimale étant de 28 Ko en statique et de 284 Ko (276 Ko) en dynamique, lorsqu'aucune commande n'est activée.

Il faut savoir que BusyBox est utilisé par un très grand nombre de projets et que beaucoup de développeurs assurent son évolution. Il est donc tout à fait envisageable de l'utiliser dans un projet industriel.

Enfin, sachant que la plupart des fonctions de base en C sont ré-écrites dans BusyBox, il serait peut-être intéressant d'y intégrer son application (qui serait alors sous licence libre). Cela pourrait faire gagner énormément de place, mais je n'ai pas testé cette éventualité.

A.2.3. Système Embutils

A.2.3.1. Présentation

Embutils est une collection d'outils comme BusyBox. Elle a été conçue dans le but d'être compatible avec la bibliothèque DietLibC (du même auteur).

A.2.3.2. Installation

Pour installer les Embutils, il faut tout d'abord modifier le fichier Makefile pour préciser où on souhaite installer les EmbUtils :

prefix?=SYSROOT

Il ne reste alors plus qu'à compiler et à installer Embutils :

bash# make
bash# make install
bash# cp -r SYSROOT/bin /mnt/ramdisk/bin

A.2.3.3. Evaluation

Le tableau suivant présente les résultats obtenus lors de la compilation des EmbUtils avec la bibliothèques DietLibC :

Tableau A.3. Evaluation d'EmbUtils

EmbUtils 0.17nombre de commandesavec DietLibC 0.29
en statique75812 Ko (280 Ko)
en dynamique75368 Ko


Comme nous pouvons le constater, EmbUtils est loin d'être aussi performante que BusyBox en ce qui concerne le rapport "nombre de commandes/taille". De plus, elle n'a pas la même maturité que BusyBox et ne possède même pas d'init ni d'interpréteur de commandes ! Le fait que le projet ne soit le fruit que d'un seul développeur rend son utilisation dangereuse en production vis-à-vis de la pérennité. Enfin, sachant qu'il n'est pas possible d'utiliser la DietLibC dans un environnement de développement croisé, il n'est donc pas possible de compiler les EmbUtils pour une cible différente de l'hôte.

A.2.4. Système K

A.2.4.1. Présentation

Système K est la collection d'outils qui est fournie avec la KlibC. Il est composé d'un ensemble de commandes utiles lors de l'utilisation d'un RAMDisk d'initialisation, on retrouve donc l'essentiel des outils de configuration.

Les RAMDisks d'initialisation sont de petits systèmes Linux utilisés lors du démarrage pour configurer le système de fichiers racine final. Ils peuvent être, par exemple, utilisés lorsque le disque racine à besoin d'une certaine configuration avant d'être utilisé.

A.2.4.2. Installation

Il faut avoir une arborescence des sources du noyau Linux correctement configurée pour compiler le Système K :

bash# cd $LINUX
bash# make ARCH=ppc menuconfig
bash# make dep #remplacer par 'make prepare' pour le noyau 2.6

Puis, il faut que le répertoire des sources du noyau Linux soit accessible par la KlibC :

bash# ln -s $LINUX KLIBC/linux

Ensuite, il faut modifier le fichier MCONFIG pour préciser quel compilateur utiliser, et où installer le Système K :

CROSS   = powerpc-linux-uclibc-
[...]
INSTALLDIR  = SYSROOT

Il existe un bogue dans la configuration de KlibC ; pour le contourner, il suffit de créer les liens suivants :

bash# ln -s klibc.config powerpc-linux-uclibc-klibc.config
bash# ln -s klcc powerpc-linux-uclibc-klcc

Enfin, il ne reste alors plus qu'à compiler et à installer le Système K (et la KlibC) :

bash# make ARCH=ppc
bash# make ARCH=ppc install
bash# cp -r SYSROOT/powerpc-linux-uclibc-bin /mnt/ramdisk/bin

Il se peut que le support du NFS ne se compile pas correctement (tout dépend de la configuration du noyau), il suffit alors d'enlever nfsmount et kinit du fichier Makefile, à la ligne suivante :

 - SUBDIRS = klibc ash ipconfig nfsmount utils kinit gzip
 + SUBDIRS = klibc ash ipconfig utils gzip

Il se peut aussi que la compilation de Ash provoque l'erreur suivante :

make[1]: *** [init.c] Segmentation fault

La solution consiste à récupérer l'exécutable mkinit d'une compilation pour l'hôte (par exemple fait à partir des sources de la Slackware) et de lancer la commande qui a échoué :

bash# cd ash
bash# cp  /Tmp/ash-0.4.0/mkinit
bash# ./mkinit arith.c arith_lex.c builtins.c cd.c echo.c error.c      \
               eval.c exec.c expand.c input.c jobs.c main.c memalloc.c \
               miscbltin.c mystring.c nodes.c options.c parser.c       \
               redir.c show.c syntax.c trap.c output.c var.c test.c
bash# cd ..

Il suffit alors de relancer la commande make ARCH=pcc. Avant d'installer la KlibC, il faut modifier son encapsuleur[27] klcc (qui permet de compiler un programme avec la KlibC) s'il ne marche pas. Pour cela il suffit d'enlever le paramètre @LDFLAGS dans les appels à la fonction mysystem.

A.2.4.3. Evaluation

Le tableau suivant présente les résultats obtenus lors de la compilation du Système K avec la bibliothèque KlibC :

Tableau A.4. Evaluation de Système K

Système K 1.0nombre de commandesavec KlibC 1.0
en dynamique24420 Ko (88 Ko)
en statique24220 Ko


Comme nous pouvons le constater, le Système K ne possède que très peu de commandes, et pourtant il prend une place non négligeable. Le projet est encore très jeune (d'où les difficultés rencontrées lors de son installation) mais possède un fort potentiel car il fait partie des projets hébergés par kernel.org (site officiel du noyau Linux). Pour le moment, il est tout de même préférable de ne pas l'utiliser dans un projet industriel.

A.2.5. Système Heirloom

A.2.5.1. Présentation

Heirloom est une collection d'outils dont le but est de fournir une très grande compatibilité avec les systèmes de type Unix, tout en ajoutant des fonctionnalités récentes. Cette dernière est basée sur la collection d'outils de l'Unix original.

A.2.5.2. Installation

Pour installer Heirloom, il faut d'abord modifier le fichier build/mk.config selon ses besoins :

ROOT = /opt/heirloom
[...]
LCURS = -lncurses
[...]
CC = powerpc-405-linux-gnu-gcc
HOSTCC = gcc
[...]
STRIP = powerpc-405-linux-gnu-strip -s -R .comment -R .note
[...]
UCBINST = /usr/bin/install

Il ne reste alors plus qu'à compiler et à installer :

bash# make
bash# make install

Si on souhaite compiler Heirloom avec la µClibC, il faut rajouter la macro suivante dans le fichier libwchar/wchar.h :

define       MB_CUR_MAX      1

Il faut aussi dé-commenter les lignes suivantes dans le fichier build/mk.config :

IWCHAR = -I../libwchar
LWCHAR = -L../libwchar -lwchar

Enfin, il faut enlever les références à nawk et oawk dans le fichier makefile, à la balise SUBDIRS.

A.2.5.3. Evaluation

Le tableau suivant présente les résultats obtenus lors de la compilation de Heirloom avec différentes bibliothèques C compatibles :

Tableau A.5. Evaluation de Heirloom

Heiloom 050612nombre de commandesavec GlibC 2.6.5µClibC 0.9.27
en dynamique1304804 Ko (2428 Ko)2692 Ko (636 Ko)
en statique13053672 Ko5712 Ko


Comme nous pouvons le constater, un système à base d'Heirloom ferait la même taille qu'un système à base de CoreUtils. Par conséquent, j'en tire les même conclusions.



[26] "shell" en anglais.

[27] "wrapper" en anglais.