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.
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=i686précise le type de l'hôte. Cette option est indispensable lorsque l'on fait de la compilation croisée.
--disable-nlsdé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).
--prefixprécise où seront installés les CoreUtils. Lors de l'installation, trois répertoires seront créés :
/bin,/infoet/man.
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.1 | nombre de commandes | avec GlibC 2.3.5 | avec µClibC 0.9.27 |
|---|---|---|---|
| en statique | 89 | 45468 Ko | 6104 Ko |
| en dynamique | 89 | 4888 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é.
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.0 | nombre de commandes | avec GlibC 2.3.5 | avec µClibC 0.9.27 |
|---|---|---|---|
| en dynamique par défaut | 98 | 1684 Ko (1396 Ko) | 598 Ko (276 Ko) |
| en statique par défaut | 98 | 908 Ko | 388 Ko |
| en dynamique complet | 205 | 2952 Ko (2124 Ko) | 1164 Ko (328 Ko) |
| en statique complet | 205 | 1880 Ko | 996 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é.
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).
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
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.17 | nombre de commandes | avec DietLibC 0.29 |
|---|---|---|
| en statique | 75 | 812 Ko (280 Ko) |
| en dynamique | 75 | 368 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.
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é.
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.
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.0 | nombre de commandes | avec KlibC 1.0 |
|---|---|---|
| en dynamique | 24 | 420 Ko (88 Ko) |
| en statique | 24 | 220 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.
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.
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.
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 050612 | nombre de commandes | avec GlibC 2.6.5 | µClibC 0.9.27 |
|---|---|---|---|
| en dynamique | 130 | 4804 Ko (2428 Ko) | 2692 Ko (636 Ko) |
| en statique | 130 | 53672 Ko | 5712 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.
