Passées les premières impressions, il est temps de préparer le terrain en vue de customiser le système ou d'en adapter un autre au Gdium en identifiant les particularités du système.

Boot

Firmware

Le firmware utilisé est PMON2000. On peut l'interrompre lors du démarrage en appuyant sur "Del" et ainsi le configurer. Il est capable de booter sur du mass-storage USB et le réseau. Sa configuration par défaut (à garder pour pouvoir continuer à booter une G-Key) va rechercher un filesystem ext2 à l'emplacement de la G-Key, sur lequel il récupèrera un kernel /boot/vmlinux.32 et un ramdisk /boot/initrd.gz. Le kernel reçoit les options suivantes via le paramètre karg de PMON:

karg = console=tty1 root=/dev/sda2 rootwait video=sm501fb:1024x600 init=/sbin/finit-mdv rd_start=0x84000000 rd_size=0x331d36

(à vérifier: les deux derniers arguments ne sont pas dans la ligne de commande lorsqu'on consulte la configuration de PMON2000.

Update 2010: la nouvelle ligne de commande est à présent la suivante, permettant plus de liberté dans le partitionnement et autorisant la mise en hibernation:

karg = console=tty1 root=LABEL=mips video=sm501fb:1024x600@60 init=/sbin/finit-mdv resume=LABEL=swap

Le kernel

Le kernel est en versin 2.6.25.4, fait 1.7 MB et prend quelques secondes pour être chargé par PMON2000. Il a l'air de contenir tout le nécessaire puisque les modules dans le ramdisk sont inexistants. Il est compil&eactue; en 64 bits.

Le kernel à charger est défini par la variable al de PMON:

al = /dev/fs/ext2@usbg0/boot/vmlinux.32

Update 2010: le kernel passe en version 2.6.29.6, et sa taille à 6 MB. Il est toujours complilé en 64 bits.

Le ramdisk initial

Le ramdisk fait 3.2 MB compressés et donc devrait être plus long à charger que le kernel. Le gros de cet espace vient de son répertoire /usr/lib (> 2 MB), plus particulièrement de libfreetype, libglib, libparted (que fait-elle là?) et libjpeg, ainsi que des fichiers de la GLIBC 2.7 dans /lib (environ 2.5 MB). Il y a donc quelques secondes de boot facilement gagnables, éventuellement au prix d'un peut d'esthétisme dans le boot, en remplaçant la GLIBC par uClibc, et en supprimant splashy et ses dépendances. Le ramdisk ne contient aucun module pour le kernel. L'initialisation du système se fait via /init, qui est un script shell. On y note le lancement de gdium-wear-levelling (contenu dans le ramdisk) et le montage du filesystem, identifié par son label (mips) et son type (ext3).

Le ramdisk à charger est défini par la variable rd de PMON:

rd = /dev/fs/ext2@usbg0/boot/initrd.gz

Le système d'init

Selon la configuration de PMON2000, c'est /sbin/finit-mdv qui est lancé. finit est un remplacement d'init conçu pour les netbooks. Sa configuration est beaucoup plus simple que l'init classique et se fait dans /etc/finit.conf. Il a reçu en argument les paramètres rd_start et rd_size que le kernel avait préalablement reçus. finit.conf est donc très simple:

user julien
host gdium
check /dev/sda2
check /dev/sda3
startx xinit /usr/bin/startgdiumwm -- /usr/bin/X -dpi 75 -br -deferglyphs all -nolisten tcp

Rien de bien compliqué donc. startgdiumwm est un simple script shell. C'est là qu'on aura plus de détails sur l'interface graphique.

En regardant dans les sources de finit, on voit qu'il lance /usr/sbin/services.sh , qui lui-même à son tour lance (entre autres) les services du runlevel 5 (/etc/rc5.d/S*).

Attention donc en configurant son démarrage: même si certaines choses sont faites pour que ça fonctionne comme avec l'init classique, ce n'est pas le cas pour tout.

L'interface graphique

startgdiumwm lance donc l'interface graphique. Il permet une certaine flexibilité en sourcant le fichier .xinitrc de l'utilisateur s'il existe. L'opération est réalisée avant la définition des variables d'environnement et autres initialisations. Tout peut donc ne pas fonctionner si on utilise cette possibilité sans précautions. startgdiumwm se trouve dans /usr/bin et d'autres scripts start* sont disponibles pour GNOME, KDE, Icewm WindowMaker et EvilWM.

La variable SDL_VIDEODRIVER y reçoit la valeur "x11". C'est sans doute l'option "kivabien" mais pas optimale. Un xhost +localhost est aussi exécuté. Outch! Heureusement que la machine est mono-utilisateur.

Le fond d'écran est auss mis en place. Sa valeur est reprise depuis les paramètres de GNOME. Bizarre, d'autant plus que le dialogue de configuration du fond d'écran n'a pas l'air d'être celui de GNOME. (à confirmer). Mais en fait, on dirait bien qu'un GNOME presque complet est installé. randr est initialisé via le wrapper /usr/bin/xrandr-display.sh (sans doute utilisé par ailleurs pour changer la sortie vidéo ou la résolution) et le gnome-settings-daemon lancé en arrière-plan. Sont aussi lancés diverses applets via les fichiers de /etc/X11/xinit.d, plus génériques que ce que le système semble proposer et pourtant avec l'air d'avoir été adaptés. LXDE n'est pas dans les dépôts, mais KDE et GNOME bien. La suite est lancée en parallèle:

• gnome-volume-manager (30 secondes après que hal soit prêt)
• idesk (icônes du bureau)
• lxpanel, la barre de menu/tâches/icônes
• les icônes de la barre des tâches (batterie, gestionnaire de volumes amovibles, gestionnaire de l'écran
• l'icône de réglage du volume (le sous-shell scrute toutes les 5 minutes l'arrivée de la socket de PulseAudio, puis attend 60 secondes avant de le lancer)
• le gnome-power-manager, avec un délai de 30 secondes
• le script run-displays, aussi avec un délai de 30 secondes; il guette toutes les 20 secondes l'activation d'une interface réseau, puis lance les 3 desklets en bas du bureau (mail, RSS, météo)
• l'applet photoapplet (écrite avec QT alors que le reste du bureau utilise plutôt GTK
• le gestionnaire de fenêtres Metacity

On a donc une explication au temps de démarrage: certains composants sont simplement démarrés plus tard, soit pour s'assurer que leurs dépendances soient prêtes, soit pour pouvoir commencer à travailler plus tôt, je ne sais pas. On note aussi plusieurs cas de polling, par exemple pour attendre le moment de lancer les desklets.

Quant à l'initialisation du système avant le démarrage du kernel, elle n'est pas instantanée non plus et pourrait ètre significativement avec un ramdisk plus petit (j'estime cette phase de chargement et décompression à 15 secondes).

Petits tests rapides

Une session gnome permet de démarrer le Gdium en un peu moins de 110 secondes. Nautilus semble compilé sans le support du bureau, sans doute pour permettre son utilisation sans interférer avec l'environnement par défaut. Il faut également lui ajouter tray_reboot dans la session pour facilement arrêter le Gdium, et à l'occasion retirer les fonctions inutiles (via gnome-session-properties).