Vim est ton ami.

Réussir son IUP avec Arch

Jean-Seb — Thu, 14 Mar 2013 18:30:00 +0100

IUP est une bibliothèque pour construire des IHM, fortement interfacée avec Lua.
Je ne sais pas comment cela se passe avec votre distribution, mais avec Arch, ce n'est pas la joie.
Notez que ce qui est décrit ici sera valable avec n'importe quelle distribution, passé les considérations préalables sur AUR.

IUP, qu'on ne présente plus.

En effet, on ne le présente plus, non pas à cause de sa renommée mondiale, mais simplement à cause du fait que si vous lisez ceci, c'est que vous connaissez déjà cette bibliothèque.

Un petit lien pour les spammeurs qui se sont perdus en ces lieux: site d'IUP

De quoi avons-nous besoin ?

IM

Il s'agit d'un toolkit pour manipuler différents formats graphiques.

La dernière version connue est la 3.8.1, celle disponible dans AUR est la 3.7.1.

ftgl

Bon alors… ft est pour FreeType et gl pour OpenGL.

Voilà donc d'une lib pour tracer du texte avec OpenGL. Mais à l'ancienne (pas de core profile).

Par chance, la dernière version peut se ramener avec pacman.

pacman -S ftgl , et n'en parlons plus!

CD

Une question me taraude à propos de tecgraf. Le font-ils vraiment exprès avec leurs noms de librairie ? Le but est-il d'être noyé dans les moteurs de recherche ? Quoi qu'il en soit, encore une lib où il vaut mieux avoir le lien direct.

Cette fois, il s'agit de Canvas Draw, qui s'appuie sur IM et ftgl.

Comme son nom l'indique, le but est de tracer dans un canevas. Présenté ainsi, cela ne semble pas très intéressant. Mais si j'ajoute que le canevas peut-être aussi bien un buffer Win32, GDI+, X11 que PDF, Postscript ou SVG, qu'en pensez-vous ?

Ah ? Bon d'accord. Néanmoins, c'est un prérequis important pour IUP. Pour ne pas changer, AUR n'est pas à jour: version 5.5 , alors que la version 5.6 est déjà disponible. Rhooo!

IUP

Celui que nous attendions tous, et qu'on ne présente plus (n'insistez pas).

Une dépendance exotique: la lib CD.

Une version un peu ancienne dans AUR : 3.2 (la 3.7 est disponible).

Mauvaise méthode : s'acharner sur son PKGBUILD.

Je vous préviens, trafiquer les PKGBUILD depréciés et buggés de AUR n'est qu'une sombre perte de temps.

Dans le principe, il semble n'y avoir que le pkgver à mettre à jour.

Dans la pratique, vous allez vous retrouver avec de mystérieux messages d'erreur lors de la compilation, et des demi-paquets comme résultats.

D'autre part, pour le paquet IUP, vous allez vous rendre compte que les modifications du PKGBUILD sont tellement importantes que vous auriez plus vite fait de le réécrire vous-même. Pour les courageux qui voudraient se lancer là-dedans, voici une partie des modifications à faire (une partie seulement, car je ne suis pas arrivé à mes fins avec cette méthode):

Changer pkgver avec la bonne version d'IUP.

Ajouter le support 64 bits: arch=('i686' 'x86_64').

libcd mal nommée (remplacer libcd par cd).

le patch du makefile est à commenter, sauf si vous gardez la version d'IUP concernée pas le pkgbuild (je ne le vous recommande pas).

les modules à compiler (par exemple, enlevez iupweb si vous n'avez pas l'environnement de compilation pour webkit).

Et tout ça pour se planter à la compilation. Il est temps de passer à …

La méthode root et artisanale.

Les petits cochons seront bien gardés.

Nous allons installer tout ceci dans ~/local

Cette méthode évite de casser votre système en polluant /usr/include/, /usr/lib , etc…

Si ce n'est pas déjà fait, il faut créer la hiérarchie local.


~$ mkdir -p ~/local/bin ~/local/include ~/local/lib
~$ ls local
bin  include  lib

ftgl ? Une paille.

ftgl a le bon goût d'être disponible dans pacman, dans la branche extra.

pacman -S ftgl

En avant avec IM.

Passons à la dépendance qui ne nécessite pas d'autres dépendances dans les projets tecgraf. J'ai nommé IM.

Chargez les sources et dépackez les dans un coin.

Nous adaptons à Lua 5.2 LUA_VER et LUA_PFX dans config_lua_module (à ne faire bien sûr que si vous utilisez la 5.2).


#Current Lua Version
LUA_VER=5.2
LUA_PFX=52

Ensuite, nous modifions le path dans tec_uname.

Le tout est de s'intercaler subtilement. Voici la partie à modifier:


ComputeSystemPaths()
{
  if [ $TEC_SYSARCH == x64 ]; then
    if [ -d /usr/lib64 ]; then
      TEC_SYSTEM_LIB=/usr/lib64
    else
      TEC_SYSTEM_LIB=/usr/lib
    fi
  else
    TEC_SYSTEM_LIB=/usr/lib
  fi

  TEC_SYSTEM_INC=/usr/include

  #ajout subtil pour forcer $HOME/local
  TEC_SYSTEM_LIB=$HOME/local/lib
  TEC_SYSTEM_INC=$HOME/local/include
  #fin de l'ajout subtil

  TEC_LUA_LIB=$TEC_SYSTEM_LIB/lua/$LUA_VER
}

Vous pouvez tester les modifications avec ce script:


#!/bin/bash
# pour tester tec_uname

source ./tec_uname

ComputeTecUname
ComputeSystemPaths

PrintInfo
echo "TEC_LUA_LIB : $TEC_LUA_LIB"

Il est temps de compiler : allez dans le répertoire src et lancez un make -j 5 do_all

Ne compilez pas le Makefile depuis la racine, ou vous obtiendrez en sortie de make un mystérieux do_all Error 2.

Pour installer IM, pas besoin de sudo comme suggéré par les scripts. Nous installons dans notre home sans avoir besoin des droits root :


~/sources/im/$ ./config_lua_module
~/sources/im/$ ./install
~/sources/im/$ ./install_dev

Notez qu'il faudra peut-être rendre exécutable ces scripts avant de les lancer. (chmod 755 …)

Vous savez quoi ? Tout n'est pas copié dans ~/local/lib.

Il faut vraiment tout faire soi même… rendez-vous dans le répertoire où les libs furent compilées, et copiez celles absentes de votre ~/local/lib.

Continuons avec CD.

Chargez les sources et dépackez les dans un coin.

Le principe reste le même que pour IM.

Changement des versions, et insertion du path $HOME/local/…

La compilation et l'installation utilisent les mêmes scripts.

(attention à faire le make depuis src, comme indiqué précédemment).

N'étant pas payé à la ligne, je vous invite donc à vous reporter à la partie précédente pour les manœuvres à effectuer.

Terminons avec IUP.

Chargez les sources, les exemples et la doc, et … vous connaissez la chanson.

Faites les modifications dans config_lua_module et tec_uname.

Il va peut-être vous falloir également modifier quelques cibles du makefile. Par exemple, si vous n'avez pas le sdk webkit installé, il faudra enlever cette cible de la rêgle do_all : iup_web.

Ce qui dans mon cas a donné (j'ai aussi enlevé la windozerie):


do_all: iup iupcd iupcontrols iupgl iup_pplot iup_mglplot iupim iupimglib iuptuio ledc iupview iuplua5 iupconsole

Alors attention, car vous allez devoir vous y prendre à deux fois. Pour terminer la compilation, il faudra installer partiellement la lib.

Lancez la compilation et l'installation, de la même facon que pour IM et CD.

Tout comme pour IM, il manque quelques libs (toujours les bindings Lua). Veillez donc à copier les libs manquantes, afin que les liens symboliques pour Lua servent à quelque chose, et que nous puissions achever la compilation.

Modifiez ensuite srclua5 et enlevez les références à lua51.

Exemple:


iuplua:
#       @$(TECMAKE_CMD) USE_LUA51=Yes
        @$(TECMAKE_CMD) USE_LUA52=Yes

Relancez make.

Installez.

J'ai également copié ce qui ressemblait fort à des helpers dans ~/local/lib/lua/5.2/. Par helpers, j'entends les fichiers *.lua que l'on trouve dans le répertoire srclua5 de IUP. Je ne leur ai pas trouvé d'utilité pour l'instant, les exemples d'IUP n'ont pas besoin d'eux.

Le présent, c'est maintenant !

Et sur ces entrefaits, il est temps de lancer le petit Hello World traditionnel, que l'on ne présente plus non plus.

Si votre prudence naturelle vous incite à ignorer les docs, voilà de quoi satisfaire à l'exercice imposé:


#!/usr/bin/env lua

package.cpath = package.cpath .. ";/home/jseb/local/lib/lua/5.2/?.so"
require "iuplua"

dlg = iup.dialog{iup.label{title="Goodbye, World!"}; title="test"}
dlg:show()

if (not iup.MainLoopLevel or iup.MainLoopLevel()==0) then
    iup.MainLoop()
end

N'oubliez pas d'adapter le package.cpath à votre config.

Vous pouvez également tester les très nombreux exemples fournis sur le site tecgraf (dans une archive dédiée).

Pour tester les exemples, je vous conseille d'exporter cette variable, qui vous évitera de modifier tous les sources avec package.cpath :


export LUA_CPATH=$HOME/local/lib/lua/5.2/?.so

Certains exemples ne fonctionneront peut-être pas, car ils nécessitent d'autres packages. Ainsi, glcanvas.wlua nécessite la lib luagl. À vous de voir.

Une dernière chose: les exemples Lua ont l'attribut exécutable, mais il vous faudra les lancer en précisant l'interpréteur Lua. Celui-ci n'est pas précisé dans la script, et si vous ne précisez pas l'interpréteur, le shell pense avoir affaire à un script shell. Je ne sais pas pourquoi j'écris ça, si vous êtes arrivés jusque ici, je ne vous apprends rien.

GUI moquait

IUP a la réputation d'être une bibliothèque particulièrement ardue à compiler. Effectivement, elle est à la hauteur de sa réputation.

Tout cela mériterait quelques beaux PKGBUILD.

Ce qui est laissé à titre d'exercice au lecteur.

Nvidia, Arch : un grand coup sur l'ABS

Jean-Seb — Tue, 05 Feb 2013 20:18:00 +0100

Si vous avez une carte graphique NVidia et que vous utilisez leur driver proprio, ceci pourrait vous intéresser.
Il vous faudra aussi être un utilisateur de Arch pour tirer pleinement parti de la quintessence cosmique de ce billet.
Dans le cas contraire, vous pouvez arrêtez de lire immédiatement et retourner faire tourner glxgears avec Nouveau, sur votre Debian.
MàJ 10/04/2013 : le nouveau paquet nvidia-libgl

Nvidia et la sauvagerie

Les blobs sont sur la plage

Si vous avez une carte video Nvidia dans votre PC, voire même un chipset de la même marque, vous utilisez forcément le driver proprio. À part bien sûr les afficionados de la 2D avec Nouveau.

C'est comme ça. Et si vous n'êtes pas d'accord avec ce qui précède, vous tournez avec un chipset Intel ou vous attendez comme le Messie la venue d'un driver open-source correct pour votre ATI (AMD aura probablement déposé le bilan avant ce jour lointain, mais splendide).

Mais pourquoi de la sauvagerie ?

Vous êtes un adepte des kernel customs.

La sauvagerie n'est pas là, le kernel custom n'a rien de mauvais en soit. C'est même une nécessité pour le support de TuxOnIce (aka «l'hibernation qui fonctionne») ou encore les drivers critiques dans le noyau (comme le RAID par exemple, au lieu d'un chargement via une image des modules placée dans un ramdisk au boot).

Cependant, qui dit kernel custom, dit également fin du support Nvidia par votre distribution.

Vous pourriez bien sûr utiliser un des affreux noyaux disponibles dans AUR, mais soyons sérieux cinq minutes. À part vous faire perdre votre temps, ceux-ci ne servent pas à grand chose, tant il vrai que d'un cas qui se veut général, ils n'arriveront jamais à vos particularités.

Haine vidia

Ne me cachez rien. Vous vous êtes retrouvés à installer les drivers Nvidia directement à partir d'une archive chargée de leur site.

Et de ce choix douteux (ne nous voilons pas la face) est né un insurmontable chaos rampant qui explose maintenant à la face de notre innocence perdue.

Pour Arch, en ce début d'année 2013, le diagnostic est simple. Vous souffrez de ces problèmes si vous avez encore des fichiers dans /usr/lib64 qui est censé être vide.


$~ ls /usr/lib64

libcuda.so            libnvidia-cfg.so.310.19       libOpenCL.so
libcuda.so.1          libnvidia-compiler.so.310.19  libOpenCL.so.1
libcuda.so.310.19     libnvidia-encode.so           libOpenCL.so.1.0
libGL.la              libnvidia-encode.so.1         libOpenCL.so.1.0.0
libGL.so              libnvidia-encode.so.310.19    libvdpau_nvidia.so
libGL.so.1            libnvidia-glcore.so.310.19    libvdpau.so
libGL.so.310.19       libnvidia-ml.so               libvdpau.so.1
libnvcuvid.so         libnvidia-ml.so.1             libvdpau.so.310.19
libnvcuvid.so.1       libnvidia-ml.so.310.19        libvdpau_trace.so
libnvcuvid.so.310.19  libnvidia-opencl.so.1         tls
libnvidia-cfg.so      libnvidia-opencl.so.310.19    vdpau
libnvidia-cfg.so.1    libnvidia-tls.so.310.19

Une vérification rapide confirme qu'il y a quelque chose de pourri au royaume des paquets.


~$ for i in /usr/lib64/lib*; do pacman -Qo "$i"; done
error: No package owns /usr/lib64/libcuda.so
error: No package owns /usr/lib64/libcuda.so.1
error: No package owns /usr/lib64/libcuda.so.310.19
error: No package owns /usr/lib64/libGL.la
error: No package owns /usr/lib64/libGL.so
error: No package owns /usr/lib64/libGL.so.1
error: No package owns /usr/lib64/libGL.so.310.19
error: No package owns /usr/lib64/libnvcuvid.so
error: No package owns /usr/lib64/libnvcuvid.so.1
error: No package owns /usr/lib64/libnvcuvid.so.310.19
 (...)
error: No package owns /usr/lib64/libvdpau.so.310.19
error: No package owns /usr/lib64/libvdpau_trace.so

Cette vérification sommaire met en évidence l'installation sauvage du driver Nvidia.

Outre le fait que ce n'est pas propre (et un driver proprio, c'est propre peut-être ? Ipso facto on s'en tape), ceci peut tuer votre Arch, ce qui est déjà plus gênant.

Exagération ? Pas de bol ?

Pas de bol: la présence de /usr/lib64, un reliquat d'Arch où vous l'avez compris ne subsiste que votre installation barbare de Nvidia, va empêcher l'installation du nouveau filesystem Arch (paquet filesystem-2013.01-3).

/usr/lib64 est censé être un lien vers /usr/lib, et non pas un répertoire rempli de fichiers.

Si vous passez outre en forçant la mise à jour , qui est couplée avec un changement de libc (pour que la fête soit complète), vous flinguez votre Arch.

Pour remédier à cela, nous allons faire le ménage, qui passe notamment par la préparation d'un paquet Nvidia format distrib, adapté au kernel customisé.

Préparer un vrai paquet Nvidia

Lancez la commande abs pour mettre à jour la liste des PKGBUILD.

Copiez /var/abs/extra/nvidia/ à un endroit où vous allez préparer le paquet.

Vous allez devoir modifier les fichiers PKGBUILD et nvidia.install.

Vous aurez besoin de votre version de noyau, obtenue avec uname -r


~/abs/nvidia$ uname -r
3.6.0+

nvidia.install

Dans nvidia.install, remplacez la valeur de EXTRAMODULES avec la chaine obtenue avec uname -r

Par exemple:

Valeur originale: EXTRAMODULES='extramodules-3.7-ARCH'

Valeur après remplacement: EXTRAMODULES='3.6.0+'

PKGBUILD

Remplacer la valeur de _extramodules avec la chaine obtenue par uname -r

Il va également surement falloir éditer les dépendances. Je n'ai laissé que ceci pour depends:


depends=()                                                                  
#makedepends=('linux-headers>=3.7' 'linux-headers<3.8')

C'est à dire rien. Les entêtes sont plus sources d'ennuis qu'autre chose, vu que nous allons utiliser celles de notre kernel (ça peut servir comme indication si votre kernel est vraiment ancien et qu'il est temps de mettre à niveau).

Il y avait bien nvidia-utils, mais nous retrouverions dans la situation dite de la poule et de l'œuf: lequel installer en premier ? (il semble qu'il n'y a pas ou plus de dépendance vers le paquet nvidia lors de l'installation de nvidia-utils. Vous pourriez donc le laisser si vous avez peur d'oublier son installation subséquente.)

makepkg

Et voila, plus qu'à lancer makepkg.

Si vous suivez la doc Arch, la victoire semble à portée de main.

Seulement, la doc Arch est rédigée par d'incurables optimistes vivants dans une sorte de pays de Cocagne, où les plus beaux jambons sont toujours à portée de main. Dans notre monde imparfait, pour rester dans l'analogie, vous vous trouvez au sommet du mat, prêt à vous saisir de la plus belle pièce, quand soudain vous vous mettez à glisser inexorablement tandis que vos bras battent frénétiquement et stupidement l'air.

Adieu veau, vache, jambon et paquet Arch.

Mais ce n'est pas grave, nous avons l'habitude, et ce n'est que partie remise. Voyons voir…


==> Starting build()...
cat: /usr/lib/modules/3.6.0+/version: No such file or directory
==> ERROR: A failure occurred in build().
    Aborting...

Ce couillon de makepkg cherche un fichier nommé version qui n'existe pas.

Voyons voir avec un noyau Arch officiel ce qu'il est censé y trouver…


/usr/lib/modules$ find -name "version"
./extramodules-3.6-ARCH/version
/usr/lib/modules$ cat extramodules-3.6-ARCH/version 
3.6.11-1-ARCH

Ok. Donc uname -r , one more time. Quelque chose m'échappe dans cette façon multiple d'acquérir la même information.

Je pourrais modifier les fichiers de config de makepkg, mais autant passer root et faire (dans /usr/lib/modules) …


/usr/lib/modules# uname -r >$(uname -r)/version

Afin de lui donner ce qu'il désire.

Voila, nous relançons makepkg et cette fois-ci, nous obtenons un beau paquet nommé nvidia-313.18-2-x86_64.pkg.tar.xz .

Installation

Module kernel.

Je vous quitte un instant, le temps de passer sous une console pour installer mon paquet tout frais démoulé.

N'oubliez pas que pour vos paquets hors circuit officiel, il faut utiliser -U et non pas le traditionnel -S.


~# pacman -U /home/vousmême/abs/nvidia/nvidia-313.18-2-x86_64.pkg.tar.xz

Et voilà.

Vous aurez peut-être besoin d'enlever les anciens paquets relatifs à nvidia, selon la façon dont vous massacrâtes votre installation.

La suite de façon classique

Vous pouvez continuer de façon conventionnelle avec les paquets officiels Arch.

Comme nous avons utilisé une base ABS pour le driver kernel, ceux-ci seront à niveau.


~# pacman -S vdpau

~# pacman -S nvidia-utils

ATTENTION ce n'est pas fini! Depuis peu (j'écris ceci en avril 2013), les libs de nvidia-utils sont installées dans /usr/lib/nvidia. Vos programmes ne vont donc plus les trouver.

Résistez à l'envie d'ajouter une entrée dans /etc/ld.so.conf, et installez plutôt le nouveau paquet : nvidia-libgl. Il contient des symlinks vers la libGL ainsi que la libglx.

Il sera peut-être nécessaire de relancer X ensuite.

nvidia-utils n'installe que la partie 64 bits des utilitaires (libGL et compagnie).

Pour la partie 32 bits, il vous faut le repo multilib.

Si ce n'est pas déjà fait, décommentez ou ajoutez les lignes suivantes dans /etc/pacman.conf.


[multilib]
Include = /etc/pacman.d/mirrorlist

Et vous pouvez dès lors procéder avec:


pacman -S lib32-nvidia-utils

À vous les jeux proprios compilés pour la couche d'émulation 32 bits d'Ubuntu. Vous n'avez pas honte ? Mettons que je n'ai rien vu (j'ai intégré ceci dans la doc uniquement par souci d'exhaustivité).

Un peu de nettoyage

Si au cours des installations des paquets le linker (ld) râle à propos de bibliothèques dupliquées, il s'agit des scories laissées par l'installation sauvage des drivers.

Dans ce cas, il faut noter les noms, et passer un coup de pacman -Qo pour trouver quel fichier n'est pas rattaché à un paquet. Pour tous ces fichiers orphelins, une seule solution: rm.

Normalement, vous devriez vous retrouver à effacer l'intégralité de /usr/lib64. À ne pas confondre avec /lib64 qui est aux dernières nouvelles un alias vers /usr/lib.Tout comme /usr/lib64 est un alias vers /usr/lib. (pour faire court, toutes les libs sont maintenant dans /usr/lib).

Attention à ne rien effacer sans vérifier auparavant que le fichier ne vient pas d'un paquet Arch. Il est vrai que tant que vous vous limitez aux fichiers Nvidia, vous ne risquez pas grand chose (à part lire ce blog depuis lynx à votre prochain reboot).

IgnorePKG dans pacman.conf

Pour ne pas avoir à recommencer la manipulation à chaque changement mise à jour globale (pacman -Su), vous pouvez mettre ces paquets en ignore dans pacman.conf.


IgnorePkg   = nvidia nvidia-utils lib32-nvidia-utils

Vu de loin, cela semble très bien. En effet, un pacman -Su va ignorer toute la partie nvidia, et vous resterez avec vos vieux drivers (de toutes façons, à part avec une carte très récente, il ne faut pas rêver. Au bout d'un an, plus rien n'est ajouté pour votre modèle dans le gros blob nvidia).

Attention cependant si vous compilez un nouveau noyau perso, et qu'entre temps un nouveau nvidia-utils est sorti.

En effet, dans ce cas vous allez réinstaller votre paquet nvidia. Mais le pacman -S nvidia-utils va ramener une version plus récente du driver, et vous allez vous retrouver désynchronisé par rapport à votre désormais obsolète driver kernel.

Vous pouvez tout mettre à niveau en repackageant un nouveau driver nvidia correspondant au niveau de version des nvidia-utils.

Ou encore, vous pouvez réinstaller les anciens paquets (que vous trouverez mis en cache dans /var/cache/pacman/pkg/). Vous pouvez installer ces paquets de la même façon que votre paquet personnel, c'est à dire en utilisant pacman -U en lieu et place de pacman -S.

Le calme est revenu sur l'ensemble de la distrib

Fini la gruikerie.

Là j'avoue, je l'avais un peu cherché quand même.

«Il faut savoir reconnaître ses torts afin de taper plus fort sur ceux qui ne le font pas.» (A. Einstein)

(ou était-ce Socrate ?)

(peut-être Napoléon…)

Installation du diablotin

Jean-Seb — Thu, 20 Dec 2012 19:18:00 +0100

Vous ne rêvez pas, je monte un serveur en FreeBSD.
Le desktop attendra encore un peu, le temps que Lennart ait transformé tout l'écosystème Linux en une gigantesque Red Hat.
Je ne compte pas pondre un billet indigeste, et je vais dans un premier temps me contenter d'une approche prudente de notre candidat fourchu.

Où trouver des informations

L'indispensable

Ce billet n'est qu'un court résumé de l'excellent FreeBSD Handbook , disponible gratuitement sur le site de FreeBSD.

Il est assez épais (plus de 1000 pages), mais du coup assez complet. Sa lecture est plus que recommandée, mon objectif ici étant principalement de résumer les particularités de BSD par rapport à Linux.

Je vous conseille de le lire en anglais, vous aurez la version la plus à jour.

Lisez le avant de poser une question sur IRC ou sur les forums. Je sais qu'on dit ça pour toutes les docs, mais là, vous allez sentir la différence si vous ne le faites pas.

Cliquez ici pour la doc html.

Pour une lecture hors-ligne ou dans d'autres langues.

Le dispensable

Si vous voulez un vrai livre en papier, «FreeBSD 7.0, le guide complet» de Michael W. Lucas (Pearson) est un bon moyen de débuter.

Il s'agit de la traduction de «Absolute FreeBSD, 2nd edition».

Le livre est sommairement traduit, mais il se lit malgré tout facilement, et contient une bonne base pour démarrer facilement.

La partie technique n'est pas très pointue et ne remplacera pas le handbook. Par contre, après lecture, vous comprendrez mieux l' «esprit» un peu particulier de la communauté BSD.

Attention, ce livre couvre la version 7 de FreeBSD. Il y a eu pas mal de changements depuis, notamment dans la gestion des packages.

Tester avec le live-cd (pour les méfiants)

Vous hésitez encore ? Comme je vous comprends.

Vous pouvez tester avec un shell à partir du CD. Le choix est proposé après la séquence de boot (test ou installation).

Si vous désirez modifier la configuration par défaut, vous aurez besoin de quelques manipulations. En effet, /etc n'est pas monté en ram et reste sur le CD.

Ramdisk pour `/etc`

Par défaut, /etc est en lecture seule. Cela empêche toute modification des fichiers de config, notamment le démarrage du dæmon sshd. (les clés de la session ne peuvent pas être écrites, et sshd ne démarrera donc pas).

Ceci permet de modifier les fichiers dans /etc en remontant ce répertoire en ram.


mkdir /tmp/ramdisk
mdmfs -s 256M md10 /tmp/ramdisk
cp -a /etc/* /tmp/ramdisk
umount /dev/md10
mount /dev/md10 /etc

La commande mdmfs sert à configurer et monter un système de fichier en RAM. Par défaut ce système de fichiers est formaté en UFS (le formatage standard FreeBSD).

mdmfs utilise le driver md (man 4 md)

On peut tester immédiatement le bon fonctionnement en démarrant le dæmon sshd: /etc/rc.d/sshd onestart

Activer l'interface réseau

Maintenant que nous avons lancé sshd, il est temps d'activer l'interface réseau.

/etc/rc.d/netif start

Ce qui active sur ma machine les interfaces: lo0 et em0.

dhclient em0 : pour obtenir une IP sur mon interface ethernet.

Installons d'abord (nous réfléchirons ensuite)

Insertion du CD

J'ai utilisé l'image d'installation FreeBSD 9.0. Pour la récupérer, je vous fais confiance, si vous lisez ce blog, vous êtes de grandes personnes.

Pas grand chose à dire sur l'installation en elle même. Belle interface ncurses, qui me rappelle ma vieille Slackware, snif. Cela dit, c'est toujours mieux que la nouvelle «interface» d'installation de Arch. Sans vouloir être blessant.

Partitionnement

J'ai utilisé le partitionnement automatique, qui m'a paru très bien. À part vouloir partager le disque entre plusieurs OS, vous ne devriez pas avoir besoin de faire un partitionnement manuel.

À noter que le partitionnement automatique utilise GPT à la place de MBR. Vous ne devrez donc surtout pas pas utiliser fdisk pour gérer votre disque, mais bien gpart.

Voici le schéma de partitionnement, choisi automatiquement par l'installateur:


ada0 232GB GPT
  ada0p1   64Kb (freebsd-boot)
  ada0p2  228Gb (freebsd-ufs)  /
  ada0p3    4Gb (freebsd-swap) none

Vous allez lire ici et là de longues dissertations sur un partitionnement très pointu, avec une partitions pour /usr, une pour /var, une pour /tmp (voire même celle-ci montée en ram), une cuillère pour /papa … ASSEZ ! Mettez tout sur la même partition, et montez éventuellement d'autres disques à partir de votre root.

Cela dit, vous faites comme vous voulez, mais ce n'est pas la peine de se compliquer inutilement la vie, les difficultés viendront bien assez vite. De toutes façons, à part ventiler les données volumineuses sur plusieurs disques (à l'époque où le tera-octet coûte 50€ ?), cela n'a aucun intérêt. Quand un disque claque, ce n'est pas avoir créé plein de partitions dessus qui servira à quoi que ce soit. Monter un RAID me parait plus judicieux (couplé bien entendu à des sauvegardes régulières et dans les rêgles de lard GRUIIIIIK!)

Et maintenant, quelques mots à propos du partitionnement sauce FreeBSD.

Nom des disques

da = disque dur scsi
ad = disque dur atapi ou sata (contrairement à Linux où le SATA est nommé comme du SCSI).
ada = disque dur sata (avec le nouveau driver).

Système de fichier

Sur FreeBSD 9, le système de fichiers par défaut est ufs2. newfs sert à créer des systèmes de fichier.

Vocabulaire spécifique aux partitions en MBR

slice = c'est une partition au sens habituel (MS-Windows, Linux).

partition = c'est un segment dans la slice BSD.

Exemples:

ada0s1 : premier disque dur, première partition primaire. Pas de numéro de partition, c'est donc un formatage MS-Windows ou Linux (si MS-Windows, surement le C:)
ada0s5 : premier disque dur, première partition logique dans la partition étendue. Pas de numéro de partition, donc c'est un formatage MS-Windows ou Linux.
ada0s1a : premier disque dur, première partition primaire, premier segment dans cette partition (s1 est le slice, a est le numéro de partition au sens BSD).

Vocabulaire spécifique aux partitions en GPT

En partitionnement GPT, tout est beaucoup plus simple: la limitation MBR à quatre partitions primaires n'existe plus.

Nous avons droit à 128 slices par disque, ce qui devrait suffire à tout le monde.

À table

Ensuite, vous sélectionnez les groupes de paquets que vous désirez installer, et c'est parti. Comme il n'y a plus rien à faire avant un certain temps, vous pouvez vaquer à vos occupations.

(un peu plus tard)

Et voilà, c'est installé. Plus qu'à choisir un mot de passe pour root, configurer son/ses interface(s) réseau, et reboot.

Particularités à connaître (ou: «fini Linux, fiston»)

Déplacement dans le buffer d'une console.

Le déplacement dans un buffer n'utilise pas shift+PageUp/Down, comme sous Linux.

À la place, utilisez Arrêt Défil , qui activera le défilement de l'affichage.

Les touches du curseur, ou PageUp / PageDown assureront le déplacement dans le buffer.

Arrêt Défil à nouveau pour revenir dans le mode normal.

Ordre des paramètres.

Sous BSD, l'ordre des paramètres est important. Ils suivent directement la commande.

ls / -lha fonctionnait sous Linux, mais pas sous BSD.

ls -lha / fonctionnera partout (oh non, nous allons devoir réécrire tous nos scripts!)

Notez que find garde son comportement : les paramètres se trouveront toujours à la fin, et ne suivront pas la commande.

Clavier en français sous la console

Il faut utiliser les capabilities.

Éditer le fichier /etc/login.conf et ajouter:


    french|French Users Accounts:\
    :charset=UTF-8:\
    :lang=fr_FR.UTF-8:\
    :tc=default:

Ce fichier doit être hashé pour être reconnu par le système. On procède ainsi (en root):

cap_mkdb /etc/login.conf

Une fois la «capabilitie» ajoutée, il faut la préciser dans le fichier password.

Pour éditer ce fichier, il faut utiliser la commande vipw

Ajoutez le nom de la «capabilitie» après les informations de groupe

jseb:$rTfM1337a$42Lee7WtF666B0fH.:1001:1001:french:0:0:User &:/home/jseb:/bin/tcsh

Et pour ne plus avoir à le faire pour les autres utilisateurs, on peut parait-il ajouter dans /etc/adduser.conf.

defaultclass = french

Ceci n'a pas fonctionné sur mon système et les nouveaux utilisateurs doivent toujours être ajoutés dans le groupe «french» avec vipw. Peut-être un paramètre à préciser à adduser, une lecture sommaire de la page man dédiée ne m'en a pas appris plus. Ayant très peu d'utilisateurs sur mes machines, j'avoue ne pas avoir cherché plus loin.

Si vous ne l'avez pas déjà fait à l'installation, précisez dans rc.conf la disposition du clavier:


keymap="fr.iso.acc.kbd"

Et pour avoir changer la disposition clavier de façon ponctuelle: kbdcontrol -l fr.iso.acc

Particularités de tcsh

Avoir less comme pager

Par défaut, les pages man sont lues avec more.

more sous FreeBSD permet d'avancer, de reculer, mais quitte à la fin. Ahah! Démasqué! C'est un less en mode compatibilité avec more.

Il suffit donc de changer la variable d'environnement PAGER.

Oubliez export , le shell par défaut est tcsh.

set ne vous aidera pas beaucoup non plus.

La bonne méthode est setenv PAGER less

Un prompt qui ressemble à quelque chose


set prompt="%n@%/%# "

De la couleur avec ls

Rajouter dans ~/.cshrc


setenv CLICOLOR yes
setenv LSCOLORS "GeHxcxdxgxegedabagacad"

man csh pour les codes couleurs de LSCOLORS. Pour colorier par extension, il vous faudra la version GNU de ls.

Avoir une touche DELETE qui supprime

Rajouter dans ~/.cshrc


bindkey "\e[3~" delete-char

Changer de shell

Vous êtes allergique à tcsh/csh, et vous voulez revenir à cette vieille daube de bash.

Pourquoi ne pas faire une tentative avec zsh ? Quoi qu'il en soit, voici de quoi changer de coquille.

Attention au changement de shell pour le compte root ! (ceci ne concerne que les afficionados des partitions multiples).

Si le shell de remplacement se trouve dans /usr, il y a un risque. En cas de problème, si /usr ne se trouve pas sur la partition racine, root ne pourra pas se logger!

Cela étant, vous avez deux méthodes pour changer de shell

(dans tous les cas, vous devriez autoriser votre shell dans le fichier /etc/shells )

Lancer chsh . Ex: chsh -s /usr/local/bin/bash root

L'invoquer depuis le fichier .cshrc . csh est le shell par défaut, il se lancera et invoquera ensuite le shell désiré.

Connaître son système

Vous avez toute une panoplie de commandes pour avoir des renseignements sur votre système.

uname -a : version et release de votre FreeBSD.
- voir également /var/run/dmesg.boot

dmesg : messages du noyau (donc matériel detecté au boot et drivers chargés).

env / setenv : vos variables d'environnement pour le shell.

kenv : afficher les paramètres du kernel en cours d'exécution.

systat : vous permet de collecter des informations sur la charge système, les processus, les interfaces réseaux. C'est très puissant ( man systat ).

Mise à jour du système

Après une installation depuis un media un peu ancien (version 9.0 pour ma part), il peut être souhaitable (voire nécessaire) de procéder immédiatement à un upgrade du système.

Les upgrades système ne font pas appel aux commandes de gestion des paquets, et sont donc à part.

Il faut utiliser freebsd-update

Cette commande permet de faire une mise à jour binaire (pas de sources nécessaires).

Il est également possible de faire une mise à jour à partir des sources, mais cela semble moins évident (voir make world dans le handbook, mais cette méthode semble largement dépréciée).

À noter que si vous n'êtes pas dans votre bac à sable, il est plus prudent de faire une sauvegarde entière du système avant de vous lancer dans ce genre de mise à jour.


freebsd-update fetch install

Cette commande fait les mises à jour pour la release installée (9.0 pour moi).

Elle récupère (fetch) les mises à jour et les installe dans la foulée. Vous pourriez bien sûr le faire en deux étapes (fetch, puis install).


freebsd-update upgrade -r 9.1-RC1
freebsd-update install
shutdown -r now
freebsd-update install #cette fois, pour userland
shutdown -r now #c'est pas vrai, faut encore rebooter ?!

Cette série de commande change de release. Attention, à l'heure où j'écris cela, la 9.1 est encore expérimentale, comme en témoignent les lettres «RC» (release candidate).

À part ça, il semble qu'il faille rebooter deux fois.


freebsd-update IDS

Cette commande récupère un fichier de checksums sur un serveur officiel (c'est souhaitable), et vérifie que les fichiers du système correspondent. Très cool pour vérifier que vous n'êtes pas rooté.

Bien entendu, dans la configuration de base, les fichiers que vous avez modifié vont générer une alerte.

Troubeulchoutine

root et password

Vous voulez changer le password de root, utilisez la commande passwd

N'utilisez pas chpass pour éditer le mot de passe! Le champs Password attend un hash, et non pas un mot de passe en clair! Vous ne pourriez plus vous relogger en root.

mot de passe root perdu

Booter en single user (menu 4 du boot pour FreeBSD 7.1)

Remounter la partition racine en RW : mount -u /

Mounter tous les systèmes de fichiers: mount -a

Lancer la commande passwd root et entrez votre nouveau mot de passe.

Rebootez.

Alors, ils mangent des enfants chez #freebsd ?

Si vous avez bien lu la doc, vous serez bien accueilli, et vous obtiendrez une réponse à vos légitimes questions de Linuxien.

La prochaine fois, je vous parle de la gestion des paquets. Croyez-moi, cela vaut bien un billet à part.

SSD - nouveau disque, nouveaux problèmes

Jean-Seb — Sun, 24 Jun 2012 17:01:00 +0200

Je suis depuis peu l'heureux utilisateur d'un portable équipé d'un disque SSD.
Voici comment l'utiliser avec Linux de façon optimale.
Les manipulations se feront depuis une Arch.

GPT et UEFI

GPT : remplace le partitionnement classique avec MBR (limite: 4 partitions).
UEFI : remplace ou complète (selon les constructeurs) le BIOS. Même principe, plus de fonctionnalités (y compris de vous interdire l'accès à votre machine au boot).

Mais j'ai déjà installé Linux !

Snif, format et réinstalle ?

Mais non, on peut s'en tirer. Et on va en profiter pour taper quelques commandes pas forcément disponibles à l'installation.

D'un autre côté, nous n'aurions pas eu besoin de taper ces commandes pour préparer un disque vierge.

Identification du hardware

lshw

J'en profite pour ouvrir une parenthèse et parler d'un paramètre de lspci qui permet de connaître les modules rattachés à un device:

lspci -k

Sauver ce qui a déjà été installé à l'aide d'une clé usb

Clé usb montée sur /mnt/clef
Disque remonté sur /mnt/disk (cf plus bas)


#~ mount -o bind / /mnt/disk
#~ tar czpCf /mnt/disk /mnt/clef/mondisque.tar.gz .

Explications du tar:

czp : créer l'archive, comprimez les données, préserver les permissions
Cf /mnt/disk : C permet de chrooter sur le répertoire /mnt/disk (on restaurera ainsi /sbin et non pas /mnt/disk/sbin).
/mnt/clef/mondisque.tar.gz : archive à créer (argument du flag -f vu ci dessus et indiqué au dessus pour des raisons de lisibilité, alors qu'il serait mieux à côté de cette option, mais avec tar on ne fait pas toujours ce que l'on veut.)
. : partir de /mnt/disk
Si vous avez de la place sur la clé usb, enlevez le flag -z , la copie sera dix fois plus rapide.

Et voila, si vous aviez installé un Linux, vous voila prêt pour tout effacer et le récupérer rapidement ensuite.

Partitionnement avec gptfdisk

Le GPT, qu'est-ce donc ?

GPT remplace le MBR.

Il y a en plus des subtilités selon que votre carte mère a un bios classique ou le support UEFI.

Les cartes mères récentes n'ont plus de BIOS, mais un UEFI («support firmware étendu») qui remplace celui-ci, avec les mêmes missions.

Préparation des outils

Boot sur un media d'installation
Activer le réseau. Au hasard: dhcpcd eth0
Mettre à jour la liste des paquets: pacman -Sy
Charger gptfdisk, pour le partitionnement: pacman -S gptfdisk
- Avec une distrib récente, gptfdisk sera présent sur le media d'installation.

Schéma de partitionnement et boot futur

Nous sommes obligés d'abandonner grub qui ne supporte pas le partitionnement gpt.

Pour ma part, j'ai choisi grub2, qui m'a l'air d'être le choix le moins pire.

Les bios non-UEFI nécessitent la création d'une partition de 2 Mo au début du disque.

Cette partition sera utilisée par grub2 pour stocker des informations.
Le Dell 6420 a l'air d'avoir un firmware bâtard, entre le bios et l'uefi. Dans le doute, et après avoir lu des choses très méchantes sur son support optimus+uefi, j'ai activé l'option legacy. J'ai donc créé la partition nécessaire à grub2.

Attention, car avec un partitionnement GPT utilisé sans UEFI, vous ne pourrez plus installer un MS-Windows sans grosses bidouilles.

Il vous faudra rajouter des partitions dans le mbr (cela s'appelle un hybrid mbr quand c'est utilisé en parallèle avec le gpt).
http://www.rodsbooks.com/gdisk/hybrid.html

Utilisation de gdisk

A conventional GPT disk contains a protective MBR with a single partition, of type 0xEE (EFI GPT), defined. This partition spans the entire size of the disk or 2 TiB, whichever is smaller. The intent is to keep GPT-unaware OSes and utilities from trying to modify the disk.

gdisk remplace fdisk

Lancez gdisk sur votre device (ex: /dev/sda).

Si votre disque est au format MBR (livré partitionné à l'ancienne), une conversion automatique sera appliquée.
Vous devez valider la conversion (avec w) et quitter.
Sinon, vous pouvez créer une nouvelle table de partition GPT avec la commande o.

Ensuite, vous pouvez commencer à créer des partitions avec n

Nous commençons par la partition de 2 Mo, réservée à grub2.

Cette partition ne doit pas forcément être la première, mais elle doit se trouver sous les deux premiers téraoctets (ce qui nous laisse un peu de marge pour les disques SSD).
n
numéro de partition : 1
Premier secteur : validez, l'alignement sera automatique.
Dernier secteur : +2M
Hex code ou GUID : EF02

Ensuite, partition Linux (data)

Même principe que ci-dessus.
Hex code : 8300

Et enfin, partition swap pour l'hibernation

Hex code : 8200

C'est fini. On écrit les modifications et on quitte.

w (pour ceux qui n'ont pas suivi)

Voilà, il ne reste plus qu'à formater les partitions à la manière habituelle (mkfs.ext4 /dev/sda2 -L linux_root par exemple).

Support Kernel de GPT

Si vous compilez vos noyaux vous-même, vous aurez besoin d'activer cette option:

FS/Partitions : cocher PARTITION_ADVANCED
Une fois cette option activée, choisissez : EFI GUID Partition support.

Dans le cas contraire, vous allez vous taper un kernel panic lors du mount de votre partition Linux.

Le Kernel Panic indiquera qu'il n'a trouvé que sda1 (si vous n'avez qu'un disque, sinon ça sera un autre device bien sûr).
Ce device correspond en réalité à l'unique partition visible sous le système de partitionnement MBR (en d'autres termes, sda1 est la partition de protection MBR créée par GPT).

Installation et configuration de GRUB2

Avec la partition linux ssd sur : mount /dev/sda2 /mnt/dest


# modprobe dm-mod
# mount -o bind /dev /mnt/dest/dev
# mount -t proc /proc /mnt/dest/proc
# mount -t sysfs /sys /mnt/dest/sys
# chroot /mnt/dst bash
# pacman -Sy
# pacman -S grub2-bios
# tar cpzf vieux_grub.tar.gz /boot/grub 
# mv /boot/grub /boot/vieuxgrub
# grub_bios-install --boot-directory=/boot --no-floppy --recheck /dev/sda
# grub-menulst2cfg /boot/vieuxgrub/menu.lst.pacsave /boot/grub/grub.cfg

Le module dm_mod (device mapper) a l'air requis.

Sans lui, grub-probe semble avoir du mal à détecter les disques et les partitions. Il est nécessaire de le charger avant le chroot.

Sauf que ça ne boote pas

Cette commande est insuffisante


# grub-menulst2cfg /boot/vieuxgrub/menu.lst.pacsave /boot/grub/grub.cfg

En effet, mes partitions sont décalées depuis la création de la première (dédiée à grub).

On peut tester l'ajustement des indices avec l'option e depuis grub, au boot.

Ensuite, il convient bien sûr de modifier de façon permanente /boot/grub/menu.cfg

J'ai également eu un problème de nommage des partitions. n'avais pas mis le même label quand je les ai recréées.

Il suffit de les renommer:


# e2label /dev/sda2 arch_root
# mkswap /dev/sda3 -L arch_swap

Support du TRIM


tune2fs -o discard /dev/sda2

Vous pouvez également le préciser dans /etc/fstab

notez le flag discard dans les options de montage de la partition arch_root.
le flag noatime est expliqué juste en dessous, un peu de patience…


LABEL=arch_root / ext4 defaults,noatime,discard 0 1
LABEL=arch_swap swap swap defaults 0 0

Astuces diverses

L'option de montage noatime

Dans /etc/fstab :


/dev/sda2 /home ext4 defaults,noatime,discard 0 1

Notez l'utilisation judicieuse de discard, déja évoqué ci-dessus (pédagogie, répétition inutile ou boucle infinie dans les explications ? Je vous laisse seuls juges).

Ramdisk pour /tmp

Certaines sources vous conseillent de faire un ramdisk pour y monter /tmp.

Ce n'est pas très avisé, car /tmp n'a pas une taille prévisible. On peut y trouver aussi bien quelques fichiers de 10Ko que la grosse archive de 4Go que vous êtes en train de déplier avec midnight-commander.

À moins d'avoir vraiment beaucoup de ram, ce n'est donc pas conseillé.

Maintenant que vous voila prévenus, voici comment opérer:


none    /tmp    tmpfs   nodev,nosuid,noatime,size=768M,mode=1777        0       0

À noter qu'il me semble que l'installation de base Arch propose une ligne de ce style dans son /etc/fstab.

Compiler en ram

Il est tentant, mais dangereux de compiler dans un ramdisk.

tentant, pour les temps d'accès rapides.
dangereux, car c'est un coup à perdre toutes ses sources en cas de plantage de la machine.

On peut décider de transiger, et de ne placer que certains fichiers dans le ramdisk.

Pour ma part, il s'agit des fichiers .gch, qui correspondent à la précompilation des fichiers includes par gcc.

En C++ notamment, la lecture des fichiers include peut prendre un temps non négligeable (ce point a déja été abordé dans un autre billet, disponible dans la même collection chez les meilleurs fournisseurs d'accès).

Il n'est quand même pas bien gros ce disque

L'espace s'étiole

Le principal inconvénient du SSD vient de son prix au gigaoctet.

Vu les capacités, on ne gaspille pas.

Or, un df -h / après l'installation des choses essentielles apporte son lot d'interrogations:


~$ df -h /
Sys. fich.     Taille Util. Dispo Uti% Monté sur
/dev/root        231G  4,2G  215G   2% /

Un rapide calcul mental nous confirme que 231-4.2 devrait être plus proche de 227 que des 215 affichés.

Diantre, 12Go de perdus, mais que se passe t-il ?!

Journalisation, inodes, arrondissement des clusters... toutes les hypothèses défilent dans notre esprit perplexe.

Bon alors c'est le journal et les inodes ?


~# dumpe2fs /dev/sda2
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   arch_root
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Default mount options:    discard
Filesystem state:         clean
Filesystem OS type:       Linux
Inode count:              15335424
Block count:              61341696
Reserved block count:     3067084
Free blocks:              59292798
Free inodes:              15165485
First block:              0
Block size:               4096
Inode size:               256
Taille du journal:         128M

Je me suis permis de couper un peu la sortie.

Si on calcule la place maximale nécessaire à la gestion du disque (journal + inodes), on obtient:

(128×1024×1024) + (15335424 * 256) = 134217128 + 3 925 868 544 = environ 4 Go.
Donc potentiellement, on n'aura jamais plus que (231-4) Go utilisables sur le disque, dans l'éventualité où tous les inodes sont occupés.

Je refais le calcul avec les inodes occupés actuellement.

Pour connaître le nombre d'inodes occupés, on peut bien sûr faire Inode count moins Free inodes. On peut aussi utiliser la commande: df -i et regarder la colonne IUsed


~# df -i /
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/root      15335424 169465 15165959    2% /

Multiplions ce nombre par la place prise par un inode, et ajoutons la place prise par le journal.

Pour les valeurs ci-dessus, ce sont 169 mo qui disparaissent pour les besoins de la gestion de la partition.

Le journal et les inodes ne gonflent pas l'occupation de manière déraisonnable.

Où sont donc passés les giga restants, et qui est le vrai coupable ?

Sachant que df tient compte de l'arrondi des clusters (la taille de tout fichier est arrondie au multiple de block size le plus proche), cette hypothèse est également fausse.

<balance>C'est root le coupable !</balance>

Le coupable ne peut rester plus longtemps ignoré.

Et quand je parle de root, je ne parle pas de ce slash innocent à la base de votre arborescence, mais bien de la forme de vie carbonée assise devant l'écran et lisant cet article.

Oui, vous: root , et je le prouve.

Regardez cette ligne:


Reserved block count:     3067084

En multipliant cette valeur par la taille d'un bloc (4096), nous obtenons 12562776064.

Soit pas loin de 12 Go.
Le voila, notre espace perdu

La valeur reserved block count correspond à un espace alloué uniquement pour les besoins de root.

Ainsi, même si les utilisateurs ne peuvent plus remplir le disque, on ne se retrouve pas dans une situation difficile où même root ne peut plus intervenir.

Cela étant dit… combien de personnes utilisent ce portable déja… ah oui je me souviens, c'est moi.

Fini de trimer

À ce stade, il ne devrait pas y avoir grand choses de plus à faire pour assurer la bonne marche du SSD.

Vous pouvez maintenant profiter de taux de transferts et de temps d'accès proprements ahurissants. Du moins, pour ceux d'entre-vous qui ne sont pas déja blasés et partis sur autre chose à configurer…

…Optimus par exemple. Mais ceci est une autre histoire.

D'un Z qui veut dire Z80

Jean-Seb — Mon, 21 May 2012 22:48:00 +0200

Les outils GNU sont d'une richesse insoupçonnée. J'en veux pour preuve l'amateur de vieux micros qui va trouver avec eux tous les outils nécessaires à un développement serein.
Notez que je prends pour exemple le MSX, mais les principes sont aisément transposables.

Avertissement

Lorsque j'ai écrit ce billet, je me suis posé la question de son contenu. En effet, il reprenait mes notes, et donc mes différents essais.

Fallait-il tout reprendre afin de garder le cheminement original ? Ou risquais-je de perdre le lecteur en route ? Un billet synthétique qui va droit à la solution, ou des techniques inutiles ici, mais qui pourront reservir ?

J'ai finalement décidé que les gens qui lisent ceci sont des hobbystes qui savent ce qu'ils risquent. J'ai coupé les branches vraiment mortes, et gardé le reste.

Les parties que les gens pressés peuvent passer sont indiquées, mais j'ai la faiblesse de croire qu'il vaut mieux lire l'intégralité.

Quel assembleur pour votre Z80 ?

Un précédent billet a détaillé les principaux assembleurs disponibles pour le Z80.

Il en sortait qu'il n'y avait pas grand chose à en tirer. Développés par des gens plus ou moins inspirés , ils peinent à convaincre.

De trop rares exceptions tirent leur épingle du jeu, comme WLA DX, dont le développement est arrêté.

Vous pouvez charitablement oublier le reste.

Heureusement, il reste une piste que je n'avais pas exploré la première fois. Elle consiste à utiliser l'assembleur GNU et lui adjoindre un backend Z80.

L'assembleur GNU et le Z80

L'assembleur GNU est une valeur sûre. Il est développé par des gens compétents, et ne vous lachera pas en rase campagne. Et il ne coûte rien, alors pourquoi se priver ?

L'assembleur GNU (et son linker) sont inscrits dans le projet binutils.

L'assembleur est remarquablement générique. Il compilera sans problème du code pour pratiquement tout les processeurs existants, y compris bien sûr le Z80.

L'avantage de la généricité est qu'entre les différentes plate-formes matérielles, le fonctionnement général des outils ne change pas. À part bien sûr quelques options supplémentaires pour supporter les spécificités matérielles.

Dans le cas du Z80, il s'agira surtout de la déclaration de bloc de données et des opcodes non documentés….

L'assembleur supporte également le R800. Le R800 est un descendant du Z80, né trop tard dans un monde trop vieux.

Vous trouverez ici la liste complète des spécificités Z80 concernant l'assembleur.

La seule difficulté est d'obtenir le support Z80 dans binutils, ce qui n'est pas le cas par défaut.

Un simple backend (étage de sortie en bon français) produisant du Z80 suffit. Par chance, GNU fournit ce backend dans le tronc officiel.

Compilation du back end Z80 sous Arch-Linux

Note : pour les utilisateurs de MS-Windows, j'ai compilé une version adaptée au Z80 , à l'aide de mingw. Vous la trouverez sur le site MSX Village. Pensez tout de même à passer à Linux un de ces jours.

Récupérer les sources avec ABS

NOTE: ceci ne concerne que les utilisateurs Arch Linux. Autrement, vous pouvez simplement charger les sources depuis le site GNU.

Pour Arch-Linux, le mieux est de partir du build ABS : (pour moi : core/binutils 2.22-4 (base-devel) )

cp -r /var/abs/core/binutils/ .

Vérifiez dans le PKGBUILD que vous avez la même version.


 pkgver=2.22
 pkgrel=4
 date=20111227

Dans le cas contraire, lancez la commande abs pour mettre à niveau l'arbre abs. À noter que la correspondance de version entre le binutils Z80 et celui de votre version est facultative, et ne vise qu'à préserver une certaine cohérence sur votre système.

Dépacker les sources récupérées:


makepkg --nocheck --nobuild

nocheck est à utiliser en connaissance de cause. Il empêche la vérification des dépendances du paquet. Dans le cas présent, cela évite d'installer dejagnu, qui est un framework pour des tests unitaires. Ici, il ne sert à rien.

nobuild empêche la construction du paquet. Les paramètres par défaut n'ont pas le support Z80, et je ne souhaitais pas faire un paquet Arch des binutils obtenus. Si vous êtes courageux, vous pouvez personnaliser le PKGBUILD pour vous éviter une copie à la main des binaires obtenus, et garder un suivi de version pour les outils.

Pourquoi n'ai-je pas fait de paquet pour la distribution ?

Les fichiers sont indépendants les uns des autres, et il vaut mieux ne pas tout mélanger avec l'installation «officielle» de binutils.

Un simple ajustement du $PATH suffira.

Compilation des sources

Quelques mots sur BFD

NOTE: pour les curieux.

BFD est nécessaire pour construire la majorité des utilitaires de binutils.

C'est une bibliothéque qui s'occupe de la partie bas niveau. Elle crée une abstraction vers le hardware pour utiliser un objet commun à toutes les plateformes. BFD ne fait pas qu'envoyer de l'opcode. Fini les problèmes avec l'endianess, la taille d'un mot qui change selon les cpu. Il s'utilise même pour le debug sur les coredumps.

Un listing du répertoire source achève de convaincre le dubitatif. Nous y trouvons une impressionnante collection de plateformes supportées, ainsi que les formats de sortie les plus divers : elf32/64 bien sûr, mais aussi coff, pe, et de façon générale, tout l'exotisme du silicium.

Prenons le fichier «cpu-z80.c». Une rapide inspection confirme que le z80 et son avatar r800 sont supportés. On a les modes «strict» et «full» pour le z80, qui correspondent surement au support des opcodes documentés ou non.

GAS : l'assembleur GNU.

Alors là, mauvaise nouvelle pour le génération des targets.

La doc le dit elle-même: «There is no convenient way to generate a list of all available hosts» , ce qui se traduit par «débrouillez-vous».

Heureusement, l'aide du configure donne quelques indications, notamment sur le fait que les noms des hosts et des cibles sont stockés dans le script «config.sub».

Nous allons donc jouer un peu avec celui-ci.

Sur ma machine, il est installé ici: /usr/share/libtool/config/config.sub

Le nommage utilise un schéma tripartite de type: ARCHITECTURE-VENDOR-OS

Heureusement, des alias sont prévus, on peut les découvrir a l'entrée $basic_machine.

Comme je l'espérais très fort, il existe un alias z80. En explorant un peu, nous trouvons aussi m68000 (m68k fonctionne également). Je vous laisse chercher pour les autres architectures.

Comme nous le supposons également, avec ces deux choix «VENDOR» et «OS» prennent une valeur générique (intitulée sobrement «unknown» ou «none»).

Ex: ~/abs/binutils/src/binutils/gas$ sh /usr/share/libtool/config/config.sub z80-unknown-none

(même topo pour le 68000: m68k-unknown-none )

Bon. En réalité, la bonne cible pour z80 est «z80-coff» (le triplet ci-dessus ne fonctionnant pas, il m'a fallu tatonner un peu).

Pourquoi pas «z80-elf» ? Vous auriez pu tout aussi bien le choisir. Le format des objets n'a aucune importance, car il y a peu de chance pour tomber sur une plateforme z80 comprenant elf ou coff.

Il faudra donc ruser pour faire du fichier objet un fichier exécutable sur la plateforme cible.

En résumé, les options à passer à configure:


--prefix=$HOME/binutils
--exec-prefix=$HOME/binutils
--target=z80-coff

Ces options permettent d'éviter de polluer votre filesystem, et de faire l'installation dans votre home (pas besoin d'être root).

L'installation se fait avec le classique «make install» après la compilation.

Après le configure, lançons la compilation:

«make -jn+1» , avec 'n' représentant le nombre de threads sur votre machines (cores*ht). Par exemple «make -j5» sur un core i5 (4 cores + 1). Ceci parallélise la compilation et accélère grandement son déroulement.

Vous pouvez avoir une erreur, dûe à un flag un peu exigeant sur un fichier peu utilisé (et donc avec moins de chance d'être corrigé immédiatement dans les sources).

Si vous êtes dans ce cas (make qui s'arrête en erreur), relancez make pour repérer le fautif (un warning qui se transforme en erreur)

Je suis évidemment tombé sur ce cas de figure, sinon je n'insisterai pas aussi lourdement.

Dans mon cas, il m'a fallu exécuter dans le répertoire «gas»:


gcc -DHAVE_CONFIG_H -I.  -I. -I. -I../bfd -I./config -I./../include -I./.. -I./../bfd -DLOCALEDIR="\"votre chemin à vous le locale dir qu'il faudra adapter""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -MT tc-z80.o -MD -MP -MF .deps/tc-z80.Tpo -c -o tc-z80.o `test -f 'config/tc-z80.c' || echo './'`config/tc-z80.c

(par rapport à la compilation avec make, nous enlevons simplement le flag -Werror)

Ensuite, nous retournons à la racine de binutils, et nous relançons make

Une fois la compilation terminée et les binutils en ligne, n'oubliez pas d'ajuster le $PATH sur le répertoire contenant les programmes z80-coff-*

Exécution des objets

Nous pouvons maintenant assembler notre programme de test (cf le listing ci-dessous).

~/test/z80-coff-as -als hello_world.asm


GAS LISTING hello_world.asm                     page 1


   1 0000 FE             db $fe
   2 0001 00C0 1AC0      dw debut,fin,debut
   2      00C0 
   3               
   4 0007 0000 0000      ORG $C000
   4      0000 0000 
   4      0000 0000 
   4      0000 0000 
   4      0000 0000 
   5               
   6                    debut:
   7 c000 210D C0        LD HL,LABEL
   8 c003 7E            AFF: LD A,(HL)
   9 c004 23             INC HL
  10 c005 A7             AND A
  11 c006 C8             RET Z
  12 c007 CDA2 00        CALL $A2 ; HFDA4 ;CHPUT
  13 c00a 18F7           JR AFF
  14 c00c C9             RET
  15 c00d 5465 7374     LABEL: DEFB "Test chput",13,10,0
  15      2063 6870 
  15      7574 0D0A 
  15      00
  16                    fin:
  17                     END

GAS LISTING hello_world.asm                     page 2


DEFINED SYMBOLS
                            *ABS*:0000000000000000 fake
     hello_world.asm:6      .text:000000000000c000 debut
     hello_world.asm:16     .text:000000000000c01a fin
     hello_world.asm:15     .text:000000000000c00d LABEL
     hello_world.asm:8      .text:000000000000c003 AFF

NO UNDEFINED SYMBOLS

Nous n'en avons pas tout à fait fini, mais au moins, le code z80 se compile correctement.

Dumpons maintenant l'objet obtenu.

~/test$ hexdump -C hello_world.out


00000000  5a 80 03 00 00 00 00 00  e6 c0 00 00 0c 00 00 00  |Z...............|
00000010  00 00 04 11 2e 74 65 78  74 00 00 00 00 00 00 00  |.....text.......|
00000020  00 00 00 00 1a c0 00 00  8c 00 00 00 a6 c0 00 00  |................|
00000030  00 00 00 00 04 00 00 00  20 00 00 00 2e 64 61 74  |........ ....dat|
00000040  61 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |a...............|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  40 00 00 00 2e 62 73 73  00 00 00 00 00 00 00 00  |@....bss........|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  80 00 00 00 fe 00 c0 1a  |................|
00000090  c0 00 c0 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0000c080  00 00 00 00 00 00 00 00  00 00 00 00 21 0d c0 7e  |............!..~|
0000c090  23 a7 c8 cd a2 00 18 f7  c9 54 65 73 74 20 63 68  |#........Test ch|
0000c0a0  70 75 74 0d 0a 00 01 00  00 00 06 00 00 00 00 00  |put.............|
0000c0b0  00 00 01 00 53 43 03 00  00 00 06 00 00 00 00 00  |....SC..........|
0000c0c0  00 00 01 00 53 43 05 00  00 00 06 00 00 00 00 00  |....SC..........|
0000c0d0  00 00 01 00 53 43 01 c0  00 00 06 00 00 00 00 00  |....SC..........|
0000c0e0  00 00 01 00 53 43 2e 66  69 6c 65 00 00 00 00 00  |....SC.file.....|
0000c0f0  00 00 fe ff 00 00 67 01  66 61 6b 65 00 00 00 00  |......g.fake....|
0000c100  00 00 00 00 00 00 00 00  00 00 64 65 62 75 74 00  |..........debut.|
0000c110  00 00 00 c0 00 00 01 00  00 00 06 00 66 69 6e 00  |............fin.|
0000c120  00 00 00 00 1a c0 00 00  01 00 00 00 06 00 4c 41  |..............LA|
0000c130  42 45 4c 00 00 00 0d c0  00 00 01 00 00 00 06 00  |BEL.............|
0000c140  41 46 46 00 00 00 00 00  03 c0 00 00 01 00 00 00  |AFF.............|
0000c150  06 00 2e 74 65 78 74 00  00 00 00 00 00 00 01 00  |...text.........|
0000c160  00 00 03 01 1a c0 00 00  04 00 00 00 00 00 00 00  |................|
0000c170  00 00 00 00 00 00 2e 64  61 74 61 00 00 00 00 00  |.......data.....|
0000c180  00 00 02 00 00 00 03 01  00 00 00 00 00 00 00 00  |................|
0000c190  00 00 00 00 00 00 00 00  00 00 2e 62 73 73 00 00  |...........bss..|
0000c1a0  00 00 00 00 00 00 03 00  00 00 03 01 00 00 00 00  |................|
0000c1b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 04 00  |................|
0000c1c0  00 00                                             |..|
0000c1c2

Nous avons assemblé au format COFF.

Il est inconnu du MSX, qui bien entendu n'est pas fait pour ces subtilités modernes.

Nous voulons nous débarasser des headers et récupérer uniquement l'assemblage du fichier source. En d'autres termes, nous voulons le contenu de la section .TEXT.

Le stub MSX est contenu dans le source, et fera office de header.

Pour isoler une section, nous avons deux possibilités:

Avec objcopy, nous pouvons nous débarasser des sections COFF inutiles:

~/test$ objcopy -O binary hello_world.out hello_world.bin

~/test$ hexdump -C hello_world.bin


00000000  fe 00 c0 1b c0 00 c0 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0000c000  21 0d c0 7e 23 a7 c8 cd  a2 00 18 f7 c9 48 65 6c  |!..~#........Hel|
0000c010  6c 6f 20 57 6f 72 6c 64  0d 0a 00                 |lo World...|
0000c01b

Une autre possibilité est d'utiliser le linker binutils z80.

~/test$ z80-coff-ld.bfd hello_world.out -o hello_world.bin

Nous constatons que ces deux possibilités souffrent du même problème :le linker utilise comme adresse d'origine 0x100 (souvenir des .com).

~/test$ hexdump hello_world.bin -C


00000000  fe 00 c1 1b c1 00 c1 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0000c000  21 0d c1 7e 23 a7 c8 cd  a2 00 18 f7 c9 48 65 6c  |!..~#........Hel|
0000c010  6c 6f 20 57 6f 72 6c 64  0d 0a 00                 |lo World...|

Nous voyons bien au début: 0xc100 au lieu de l'attendu: 0xc000

Le linker peut, grâce à l'utilisation d'une configuration ld, faire beaucoup mieux que cela.

Pour l'instant, nous nous cantonnerons à utiliser objcopy. L'utilisation du linker, beaucoup plus pratique, sera abordée ensuite.

Solution sans script ld

Note : les allergiques aux commandes Unix peuvent passer directement au script ld.

Revenons au fichier produit par objcopy.

Il est presque parfait, mais nout avons toujours du padding entre l'entête (les 7 premiers octets) et la section de code, qui commence à 0xc000.

Nous voudrions plutôt cela:


00000000  fe 00 c0 1b c0 00 c0 21  0d c0 7e 23 a7 c8 cd a2  |.......!..~#....|
00000010  00 18 f7 c9 48 65 6c 6c  6f 20 57 6f 72 6c 64 0d  |....Hello World.|
00000020  0a 00                                             |..|

Avec quelques commandes shell, nous pouvons arriver facilement au résultat ci-dessus.

Créer avec le fichier de sortie hello_world.exe en copiant les 7 premiers octets, qui font office de stub :

~/test$ dd if=hello_world.bin of=hello_wo.exe count=7 bs=1

ensuite, nous avons deux possibilités pour trouver l'offset à passer pour arriver sur le code.

1) lire la valeur de l'offset du code dans le fichier source:

skip=$(awk 'BEGIN { FS="$" }; /ORG/ { print strtonum("0x"$2) }' hello_world.asm)

2) ou bien, trouver cette valeur en lisant le header du fichier binaire:

skip=$(od -d -t d1 hello_world.bin --skip=1 -N 2)

la sortie se fait en décimal (-d)

le type de la sortie est défini comme char (-t d1)

on lit deux éléments (-N 2)

on passe le premier octet (--skip=1) pour arriver sur l'adresse du symbole «debut».


   1 0000 FE              db $fe
   2 0001 00C0 1AC0 00C0  dw debut,fin,debut

Une fois la valeur skip récupérée, nous ajoutons le code au header :

dd if=hello_world.bin of=hello_wo.exe skip="$skip" bs=1 oflag=append conv=notrunc

Et voila :

~/test$ hexdump -C hello_wo.exe


00000000  fe 00 c0 1b c0 00 c0 21  0d c0 7e 23 a7 c8 cd a2  |.......!..~#....|
00000010  00 18 f7 c9 48 65 6c 6c  6f 20 57 6f 72 6c 64 0d  |....Hello World.|
00000020  0a 00                                             |..|

Nous pouvons en faire un script pour aller plus vite la prochaine fois. Ce script est donné à titre d'illustration et ne permet que de compiler un seul fichier source à la fois.

J'ai rapidement laissé tomber, pour revenir à l'utilisation du linker que nous allons voir dans la prochaine section.

~/test$ cat compile.sh


#!/bin/bash
#paramètre: source.asm "options_gas"
#Attention, les paramètres doivent être entre guillemets si il y en a
#           plusieurs séparées par des espaces.

#exemple: ./compile.sh foo.asm "-als -Wup"

#à changer selon l'emplacement de binutils
install_root="$HOME"/binutils


#pas besoin de toucher au reste, normalement
src=$1
if [ "$src" == "" ]; then
   echo "Usage:"
   echo "  $0 source.asm"
   exit
fi

options_gas="$2"

install_bins="$install_root"/z80-coff/bin/
GAS="$install_bins"as
OCP="$install_bins"objcopy


base="$(basename $src .asm)"

#si besoin est, tronque la destination en 8.3
dst="$(echo $base | cut -c1-8 )".exe
log="$base".log
out_gas="$base".out
out_ocp="$base".bin


echo compilation de "$src" " -> $out_gas"
"$GAS" "$src" $options_gas -o "$out_gas"  > "$log"
if [ $? -ne 0 ]; then exit; fi 

echo conversion de "$out_gas" " -> $out_ocp"
"$OCP" -O binary "$out_gas" "$out_ocp"
if [ $? -ne 0 ]; then exit; fi 

echo création exécutable avec "$out_ocp" " -> $dst"
dd if="$out_ocp" of="$dst" count=7 bs=1 2>/dev/null
skip=$(od -d -t d1 "$out_ocp" --skip=1 -N 2  | awk 'NR==1 { print $2 }') 
dd if="$out_ocp" of="$dst" skip="$skip" bs=1 oflag=append conv=notrunc 2>/dev/null

Pour tester, j'utilise OpenMSX qui est mon émulateur MSX favori.

openmsx -machine Philips_NMS_8255 -diska /home/jseb/test/

Une fois l'invite du basic obtenue dans l'émulateur, entrez les deux commandes:


files

bload "a.msx",r

Mais tout ceci est bien compliqué…

La meilleure solution pour un exécutable: le script ld

Nous allons créer un exécutable en utilisant le linker.

Voici comment procéder:

Enlever la directive «.ORG» du source assembleur
Ajouter des sections (plus propre pour le linker)
Compiler : z80-coff-as -als foo.asm -o foo.out


   1                    .section .stub
   2 0000 FE                db $fe
   3 0001 0000 1B00         dw debut,fin,debut
   3      0000 
   4                    
   5                    ; ne PAS utiliser la directive .ORG
   6                    ; .ORG $C000
   7                    
   8                    .section .mycode
   9                    ; par défaut, la section de code s'appelle .text
  10                    debut:
  11 0000 210D 00        LD HL,LABEL
  12 0003 7E            AFF: LD A,(HL)
  13 0004 23             INC HL
  14 0005 A7             AND A
  15 0006 C8             RET Z
  16 0007 CDA2 00        CALL $A2 ; HFDA4 ;CHPUT
  17                    ; call outside
  18 000a 18F7           JR AFF
  19 000c C9             RET
  20 000d 4865 6C6C     LABEL: DEFB "Hello World",13,10,0
  20      6F20 576F 
  20      726C 640D 
  20      0A00 
  21                    fin:
  22                     END

DEFINED SYMBOLS
                            *ABS*:0000000000000000 fake
             foo.asm:10     .mycode:0000000000000000 debut
             foo.asm:21     .mycode:000000000000001b fin
             foo.asm:20     .mycode:000000000000000d LABEL
             foo.asm:12     .mycode:0000000000000003 AFF

Notez la section .stub dans le source ci-dessus.

Vérification du contenu des sections: z80-coff-objdump -s foo.out@


foo.out:     file format coff-z80

Contents of section .stub:
 0000   fe00001b 000000                      .......         
Contents of section .mycode:
 0000   210d007e 23a7c8cd a20018f7 c948656c  !..~#........Hel
 0010   6c6f2057 6f726c64 0d0a00             lo World...

Nous voyons pour la section «.stub» que l'origine est à 0x0 pour l'instant. C'est au linker qu'il incombera la tâche de recalculer les adresses.

Nous pouvons linker, pour l'instant sans utilisation d'un script ld.

L'origine sera donc à 0x100 (origine par défaut pour ce linker)

Option -M : en plus du link, affiche le mapping mémoire:

z80-coff-ld foo.out -o foo.exe -M


Memory Configuration

Name             Origin             Length             Attributes
*default*        0x0000000000000000 0xffffffffffffffff

Linker script and memory map

LOAD foo.out
                0x0000000000000100                . = 0x100
                0x0000000000000100                __Ltext = .

.text           0x0000000000000100        0x0
 *(.text)
 .text          0x0000000000000100        0x0 foo.out
 *(text)
                0x0000000000000100                __Htext = .

.data           0x0000000000000100        0x0
                0x0000000000000100                __Ldata = .
 *(.data)
 .data          0x0000000000000100        0x0 foo.out
 *(data)
                0x0000000000000100                __Hdata = .

.bss            0x0000000000000100        0x0
                0x0000000000000100                __Lbss = .
 *(.bss)
 .bss           0x0000000000000100        0x0 foo.out
 *(bss)
                0x0000000000000100                __Hbss = .
OUTPUT(foo.exe binary)

.stub           0x0000000000000100        0x7
 .stub          0x0000000000000100        0x7 foo.out

.mycode         0x0000000000000107       0x1b
 .mycode        0x0000000000000107       0x1b foo.out

On voit (dans OUTPUT) que les seules sections trouvées furent «.stub» et «.mycode».

ld a donc linké ces sections à la suite, en l'absence d'autres instructions (c'est ce qu'on appelle un «script de link implicite»).

Pour linker correctement, il faut utiliser ce script ld , que nous spécifierons à «ld» avec l'option «-T».


OUTPUT_FORMAT(binary)
SECTIONS
     {
       .stub 0xC000 - 7 : { *(.stub) }
       .code : { *(.mycode) }

     }

z80-coff-ld foo.out -o foo.exe -T nom_du_script_ld

C'est fini

Par manque de temps (et un aussi un peu de motivation), je ne pense pas revenir sur la programmation d'ordinosaures.

J'ai quand même décidé de publier ces notes, en espérant que quelqu'un pourra en faire bon usage.

J'ai encore quelques autres notes du même acabit dans mes tiroirs. Je les publierai peut-être un jour, mais ne retenez pas votre respiration.

IRC: Wee ou non ?

Jean-Seb — Sun, 25 Dec 2011 19:29:00 +0100

Vous connaissez tous IRC, et principalement Freenode, l'auberge espagnole du Logiciel Libre.
Pour le client à utiliser, c'est une autre histoire…
Pendant des années, j'ai utilisé Irssi. Et puis, un jour…

Un jour j'en ai eu marre d' Irssi.

Irssi est le choix par défaut des utilisateurs Linux pour IRC.
Il faut dire que la concurrence n'est (n'était) pas brillante,
Pourtant, on ne peut pas dire que Irssi soit le parangon du client IRC.

Irssi la branche sur laquelle il est assis

Irssi présente de nombreux défauts, ou tout du moins de sérieuses limitations:
- son horrible fichier de configuration (colorer différement la barre de stats du buffer actif fut un vrai défi).
- un scripting limité à Perl.
- une ergonomie discutable (la configuration par défaut est inutilisable).
- une documentation incomplète et incompréhensible.

C'est vrai, il y a d'autres clients IRC

BitchX : ha-ha-ha, je vous laisse essayer (il y en a qui aiment…).
XChat : qu'il est de bon ton de dénigrer, mais qui a le mérite d'être simple. On en fait vite le tour, cependant.

Voici WeeChat

Certe, je débarque: ce logiciel existe depuis un certain temps.
- 2005 pour les premières versions exploitables.

Il est cependant toujours développé, et comprend de nombreux avantages par rapport à Irssi.
- Une doc claire et complète, et en français qui plus est.
- Une configuration aisée. Toutes les modifications sont applicables sans relancer WeeChat, et peuvent être sauvées depuis celui-ci.
- Une prise en main rapide.
- Scripting avec Lua! Yäh ! Ftaghn Cthulhu Lua ! Et pour le reste d'entre-vous, il y a aussi la possibilité de scripter en Python, en Perl, en Ruby ou en TCL.
- Possibilité d'utiliser un client différent du client ncurses proposé par défaut (pour ceux qui ont honte d'installer XChat).

Premier contact avec WeeChat

Vous retrouverez dans la doc tout ce que je n'ai évidemment pas sorti de nulle part

Comment qu'ça s'installe ?

Boudiou: pacman -S weechat
- Ne vous laissez pas impressionner par le numéro de version (en ce moment: 0.3.6).
- C'est du vrai logiciel libre pleinement fonctionnel, et qui ne cherche pas à en mettre plein la vue avec une numérotation stratosphérique des versions.

Déroulement d'une session typique

Quelques commandes de base devraient vous sortir d'affaire, sans rien avoir à configurer pour commencer.

Commençons par lancer WeeChat:
- weechat-curses

/connect irc.freenode.org : c'est une connexion temporaire, nous verrons plus loin comment la rendre permanente.
/join archlinux-fr : notez la barre des nicks sur le côté. C'est bien, mais ça prend de la place. Mais comme c'est un élément d'interface, c'est désactivable.
À ce stade, il peut être utile de savoir comment se déplacer dans les fenêtres: ALT + flèches curseur
Par défaut, une fenêtre affiche un seul buffer. Par la suite, vous pourrez afficher plusieurs buffers dans une fenêtre avec les commandes split.
- /window splith : splitte horizontalement.
- /window splitv : coupe verticalement.
- Utilisez F7 et F8 pour naviguer dans les splits.
- /window zoom : permet de sortir d'un split (raccourci: alt+z)

N'oubliez pas … /help
- Et pour une commande particulière: /help commande

Raccourcis clavier

En reprenant l'exemple de F7 et F8 pour naviguer dans les splits, on prend conscience de l'impérieuse nécessité de configurer son clavier.
Alt+k (touche) donne la touche et la commande associée.
- Ex: Alt+k F8 affichera: meta2-19~ window -1
- Ceci nous permet de passer au split précédent.

De même, nous pouvons obtenir facilement le code de la combinaison alt+curseur bas:
- Alt+k Alt+curseur bas : meta-meta2-B

Armés de ces informations, nous n'avons plus qu'à associer alt+curseur bas (par exemple) comme nouveau raccourci à window -1
- /key bind meta-meta2-B /window -1

Et pour la flèche du curseur haut associée à alt, je propose de désactiver/activer la barre des pseudos.
- /key bind meta-meta2-A /bar toggle nicklist

À vous de voir pour le reste…
- Sachez que vous pourrez être amené à éditer directement le fichier de configuration contenant les raccourcis.
- Mais uniquement en cas d'erreur bloquante, ou trop compliquée à corriger à coup de /key bind.
- Bref, rien de tout cela ne devrait vous arriver. Le fichier est .weechat/weechat.conf , section key.

Configuration de WeeChat

Une simplicité biblique

/set config.section.option valeur : pour modifier un élément de configuration.
/set config.* : pour voir un sous-ensemble de la configuration (set pour tout voir).
/help config.section.option : raison d'être d'une option précise.
/save : sauve dans un fichier de config l'état actuel de la configuration (la sauvegarde est automatique dans le fichier utilisé par WeeChat).
/reload : recharge la configuration, au cas où vous préféreriez modifier de façon externe les fichiers concernés (en cas de blocage par exemple).
/plugin : voir les extensions chargées (vous devez avoir au minimum l'extension irc).

Exemple: définir une connexion

Nous allons paramétrer une connexion permanente, dont les paramètres seront sauvegardés dans la configuration.
- /server add fn irc.freenode.org : défini un alias fn pour freenode, pour référencer la connexion.
- /set irc.server.fn.nicks VotrePseudo : si il est différent du login, utilisé par défaut. On peut préciser plusieurs pseudos, au cas où le premier serait indisponible sur ce serveur (déja utilisé par exemple, ou interdit).
- /set irc.server.fn.command "/msg nickserv identify xxxxx" : si vous voulez vous authentifier automatiquement.
- save
Et par la suite, pour vous connecter rapidement à freenode en rappellant la connexion sauvée:
- /connect fn
Pour retrouver rapidement la liste des serveurs déja paramétrés:
- /server list

La peinture facile

WeeChat possède des facilités pour la gestion des couleurs.
Tapez /color pour passer dans le buffer des couleurs.
- Vous y trouverez les paires de couleurs utilisées, ainsi que la palette utilisable dans votre terminal (avec alt+c).

Je passe sur la syntaxe pour envoyer des kikoos multicolorés dans les buffers. Vous la trouverez dans la doc.

Nous allons maintenant nous intéresser à la colorisation de l'interface.

Comme vous le savez, un /set peut être suivi d'un joker
- Pour avoir tous les paramètres liés aux couleurs: /set weechat.color.*

Avec ces informations, nous pourrions personnaliser les différents éléments de l'interface.
Pour faire original, je vais simplement changer quelques couleurs peu lisibles sur le fond de mon terminal.
- C'est extrèmement aisé, grâce au buffer color.

Vous avez sans doute remarqué que le nom des intervenants dans un chat est affiché avec des couleurs très variées.
- Les couleurs dépendens de cette variable de configuration, qui a pour valeur par défaut:
- weechat.color.chat_nick_colors = "cyan,magenta,green,brown,lightblue,default,lightcyan,lightmagenta,lightgreen,blue"
- Le choix d'une couleur sur un pseudo se fait grace à un hash sur celui-ci.
- Pour modifier la couleur de son propre pseudo, on utilise la variable weechat.color.chat_nick_self (et pour les conversations en privé, vous avez également weechat.color.chat_nick_other ).

Pour avoir la liste des codes couleurs utilisables, on a deux possibilités:
- /color dans weechat, puis alt+c
- ou depuis un terminal: weechat-curses -c
- Je préfère utiliser /color , suivi d'un e pour afficher la représentation des couleurs utilisées actuellement.

On peut rentrer des noms de couleurs, ou bien directement les codes couleurs obtenus ci-dessus. On peut également préciser des attributs.
On peut également utiliser /color alias pour nommer un code couleur dans WeeChat.

Ouvrez une fenêtre une fenêtre splittée, tapez des commandes de couleur dans l'une, et regardez le résultat dans le buffer color visible dans l'autre.
- Par exemple:
- /set weechat.color.chat_nick_colors = "118:091,232:105,238:219,234:216,152:090,10:20,255:091,118:009"

Les scripts

Lest scripts s'utilisent par le biais des extensions

Un script Weechat n'appelle pas directement les fonctions de l'API WeeChat.
Le script passe par un wrapper qui appelle ensuite l'API. Il y a un wrapper par langage de script.
Ces wrappers font partie des extensions (terminologie WeeChat).
Les extensions se controlent avec la commande plugin (/help plugin).
L'avantage de cette façon de procéder est que les différences entre langages de scripts deviennent minimes. L'inconvénient est qu'il faut écrire un wrapper pour chaque langage concerné, puisque l'accès direct à l'API WeeChat n'est pas la méthode conseillée (bien que l'on puisse surement utiliser quelque chose comme FFI du projet LuaJIT, mais cela sort largement de notre propos).

Installation d'un script existant

Avant d'écrire un script, commençons par en installer un.
J'ai choisi le bip, pour ne rien rater sur IRC.
À propos, avez-vous remarqué l'angoisse diffuse instillée par la possibilité de plus être joignable vingt-quatre heures sur vingt-quatre ? Ou pire, de rater un appel ?
- Les marchands de téléphones ont fondé leur business là dessus.

Vous trouverez le script Perl qui fait bipper dans le dépot WeeChat consacré aux scripts.
- bipper en Perl

Vérifier que l'extension Perl est chargée:
- /plugin list

Si ce n'est pas le cas, c'est probablement parce que Perl n'est pas installé (et on vous comprend).
- Il faudra donc installer Perl, et charger l'extension (pas besoin de quitter WeeChat) : /plugin load perl

Et pour charger le script:
- /perl load ~/.weechat/perl/beep.pl

Tous les scripts sont référencés ici:
- http://www.weechat.org/scripts/

Écriture d'un script minimaliste à l'aide de Lua

Une introduction
Vous aurez également besoin du guide de référence de l'API C de WeeChat

Où se trouve le wrapper Lua ?
- Comme dit précédemment, vous ne chargerez pas vous même le wrapper avec un require dans le script Lua. Vous allez devoir passer par les extensions WeeChat, qui dans ce cas consiste en un wrapper Lua vers l'api C de WeeChat.
- Il faut charger votre script de cette façon depuis WeeChat: /lua load chemin/vers/script.lua
- Attention, pour décharger le script, il faudra passer le nom défini en tant que name dans la fonction weechat.register.

Passons au script proprement dit. Il faut commencer par enregistrer son script.
- weechat.register(name, author, version, license, description, shutdown_function, charset)
- weechat.register("test_lua","jseb","0.1","beerware","pas de desc", nil, "utf-8")

On peut tenter une sortie dans le buffer core de WeeChat (celui qui affiche les messages du programme).
- weechat.print ("","ça marche")
- Notez que le print intégré à Lua, qui écrit sur la sortie standard, est fonctionnel, mais ne vous attendez pas à ce que la sortie suive la logique de votre script. Comme l'exécution du script est séquentielle, vous aurez déja la sortie de vos print, puis la reconstruction de l'écran. Cette méthode est donc déconseillée, hormis pour des messages de diagnostics pour le debug (et autant utiliser weechat.print)

Le script sera exécuté une seule fois, et ensuite il faudra le recharger pour recommencer le traitement. Il peut donc être plus pratique d'ajouter une commande à WeeChat en créant un hook.
Nous allons utiliser la fonction de l'API hook_command.
- Nous pourrions également programmer une temporisation (weechat.hook_timer) ou une commande batch (lancée en fond avec weechat.hook_procees et qui permet peut être l'écriture de coroutines, même si à mon avis weechat.hook_timer sera plus adaptée pour cela).
- Pour le transformer en commande, il faut utiliser weechat.hook_command, en précisant le nom de la commande, son mode d'emploi (pour /help et le nom de la fonction callback dans le script).
- À noter que les paramètres de la fonction callback seront imposés: buffer où a été lancée la commande, paramètres de la commande et data (non utilisé dans le script, tout passe dans la variable qui contient les paramètres).
- Description dans l'API de hook_command

Maintenant que le script est enregistré et transformé en commande, il ne reste plus qu'à transformer en majuscule la chaine passée en paramètre.
- J'utilise pour cela une fonction de la classe string de Lua, qui malheureusement ne fonctionne qu'avec les caractères ascii et ne mettra donc pas en majuscule les accents. J'aurais bien utilisé la fonction weechat_string_toupper, mais elle n'est pas disponible en dehors de l'api et semble d'après l'exemple de la doc ne pas convertir non plus les accents.

Pour afficher dans le buffer en cours, j'utilise une petite astuce. Je demande l'exécution de la commande irc say dans le buffer en cours.
- weechat.command(buffer,"/say "..la_chaine_en_majuscules)

Il aurait été tentant d'utiliser cette commande:
- weechat.print(buffer,str_up)
- mais elle ne ferait qu'afficher la chaine en majuscules dans le buffer actuel, et vos interlocuteurs ne la verrait pas.

Voici le listing complet du script:


~/.weechat/lua$ cat hello.lua 
#!/usr/bin/env lua

--pour faire un /lua reload, il faut soit que le script soit dans autoload, soit spécifier son nom (celui déclaré dans weechat.register, pas le nom de fichier). Autrement, il sera bien déchargé, mais jamais recharge.                        

function hurler_fx(data, buffer, args)
  local str_up = args:upper()
  weechat.command(buffer,"/say "..str_up)
end

--weechat.register(name, author, version, license, description, shutdown_function, charset)
weechat.register("test_lua","auteur","0.1","noware","pas de desc", nil, "utf-8")

hook = weechat.hook_command ("hurler", "script pour hurler dans un buffer",
                             "[chaine à hurler]", "la chaine que vous souhaitez hurler","",
                             "hurler_fx","")

weechat.print ("","le script est chargé")

À tester depuis weechat avec :


/lua load lua/hello.lua 
/hurler et maintenant, tout le monde va m'écouter

NB : je décline toute responsabilité en cas de kick.

Terriblement t'efficace (nanananana nanana)

J'espère vous avoir convaincu de tenter un essai avec WeeChat.
Pour en savoir en plus, je vous renvois à l' excellente documentation
Bon t'chat , lol !
Je remercie FlashCode, l'auteur de WeeChat, pour son excellent soft, et pour avoir bien voulu répondre à quelques-unes de mes questions… sur son canal IRC, bien entendu
- irc.freenode.org : #weechat-fr

Des cookies à accepter sans hésiter !

Jean-Seb — Thu, 24 Nov 2011 20:44:00 +0100

Bonne nouvelle, j'ai enfin réussi à calibrer ma recette de cookies.
Afin d'en faire profiter l'humanité, voici le résultat de longs mois d'expérimentations (c'est pour cela que je ne postais plus rien et que j'ai pris vingt kilos).
Ces cookies là, je vous le garantis, ce ne sont pas les cookies pourris de votre navigateur internet.

Merci à Marie pour la relecture, les suggestions, et les photos.

Introduction

Un magnifique spécimen: le Cookus-chocolatus-classicus

Ingrédients

200g de farine.
1 sachet de levure chimique (bicarbonate).
1 sachet de sucre vanillé.
- le sucre vanillé est facultatif, mais c'est meilleur avec.
70g de cassonade
- ou 60g de sucre en poudre si vraiment vous n'avez pas de cassonade.
60g de chocolat en morceaux.
- ou 60g de pépites de chocolat, ça vous évitera de le faire vous-même.
60g de raisins secs.
60 à 80g de noisettes grillées, selon vos goûts.
1 œuf.
5 cuillères à soupe d'huile de noix.
- qui correspondent à environ 100g. de beurre, si vous n'avez pas d'huile.
5cl d'eau (environ un tiers de verre à moutarde).
- ceci uniquement si vous utilisez de l'huile. L'eau est utilisée pour compenser la différence beurre/huile. Il y a de l'eau dans le beurre, contrairement à l'huile.
1 pincée de sel. Ne l'oubliez pas!

Pré-requis

Cette recette nécessite un peu de patience.
Elle nécessite également quelques ingrédients que vous pourrez préparer à l'avance afin de gagner du temps le moment venu.

Les noisettes

Décortiquez et coupez les noisettes en deux.
Faites revenir à la poêle, sans matière grasse.
Quand les noisettes en contact avec la poêle commencent à brunir, remuez-les pour répartir la cuisson.
Une fois toutes les noisettes brunies, retirez du feu et laissez refroidir.
- Pendant que les noisettes refroidissent, que diriez-vous de commencer le découpage du chocolat ?
Frottez les noisettes entre vos doigts et retirez la pellicule qui se détache la plupart du temps.
Les noisettes grillées peuvent se conserver quelques semaines dans un bocal en verre.
- Dans le cas d'un stockage dépassant quinze jours, goûtez une noisette avant de les utiliser.

Les pépites de chocolat

Le moment idéal pour opérer est pendant le refroidissement des noisettes.
Découpez les carreaux de chocolat en morceaux à l'aide d'un couteau bien aiguisé, sur une planche à découper.
- Avec mon chocolat, j'obtiens neuf morceaux pour chacun des carreaux. Ne vous coupez pas les doigts non plus et restez raisonnables.

Préparation

Dans un saladier

Mélangez farine, levure, sucre vanillé et la pincée de sel.
Ajoutez à la farine les noisettes grillées, les raisins secs et les pépites de chocolat.
Mélangez bien le tout, pour répartir les ingrédients,

Dans un bol

Si vous n'aviez pas d'huile, faites fondre le beurre à feu très doux et en remuant pendant toute la durée de l'opération.
Mesurez les 70g de cassonade, et ajoutez un œuf. Mélangez le tout.
Si vous utilisez de l'huile, ajoutez l'eau. Mélangez bien.
Ajoutez l'huile ou le beurre, et mélangez jusqu'à obtenir une indistincte mélasse.

Merge (bol, saladier)

Versez en trois étapes le contenu du bol dans le saladier, en remuant continuellement.
Quand le mélange présente une agglomération certaine, et qu' il devient difficile à manœuvrer, continuez le pétrissage à la main.
Stoppez quand vous obtenez une boule de pate homogène, dont les morceaux ne se décollent plus.

Le grand cylindre

Découpez une feuille de plastique transparent alimentaire.
Placez la boule de pâte sur cette feuille, en l'étirant en rouleau.
Refermez la feuille sur la pâte. Une fois bien emballée, faites la rouler sur votre plan de travail, de façon à lui donner un aspect circulaire.
Placez le tout au réfrigérateur 1/2h, ou 10mn au congélateur. Cela va donner une certaine tenue à la pâte, afin de faciliter son découpage ultérieur.

Cuisson

Découpez la pâte en cylindres de 1 ou 2cm d'épaisseur.
N'hésitez pas à rassembler le morceau en un monticule cylindrique bien aggloméré, en poussant la circonférence extérieure de vos petits doigts vigoureux.
Placez les cylindres (ou monticules, selon votre degré de finesse) de façon espacée sur du papier cuisson.
Mettre le tout sur une plaque (ou une grille si comme moi, vous n'avez toujours pas de plaque).
Faites cuire 1/4h dans un four préchauffé à 180°.
Renouvellez l'opération découpage/disposition/cuisson jusqu'à épuisement du stock ou de votre patience.
Le secret du gourmand : la pâte se congèle très bien, pour une utilisation ultérieure !

Dégustation

Là, je crois que les explications ne sont plus nécessaires !
Je n'accepte aucune responsabilité quand à une éventuelle prise de poids.
Une dernière photo pour achever de convaincre les plus indécis.

Enfin RAID!

Jean-Seb — Sun, 16 Oct 2011 19:51:00 +0200

Sous ce titre ne se cache pas l'annonce de la fermeture du blog. Que nenni! Lisez plutôt la suite, et tant pis pour la fausse joie.
Que feriez-vous si vous preniez possession de trois disques identiques ?
Mais non! Vous ne les revendriez pas sur Ebay !
Vous vous monteriez un RAID, bien sûr !

Remerciements particuliers à Frédéric Jolliton, qui m'a donné un sérieux coup de main.

Dis papa, le serveur il est tout RAID

Bon pas besoin d'en faire une tartine, ni d'expliquer les différentes formes de RAID.

Ici, je parlerai de deux type de RAID (RAID1 et RAID5), avec trois disques.
- RAID1 : C'est du mirroring. Chaque disque réplique complètement les autres.
- RAID5 : Chaque disque perd 33% de sa capacité, afin d'être en mesure de reconstruire un disque tombé en panne. Il faut bien sûr que deux disques soient en état de marche pour reconstruire le troisième.

Pour ceux qui veulent tout savoir
- excellent article de la doc Arch-Linux
- La doc Arch aborde également le problème du MBR sur les disques modernes, et qui pourrait vous intéresser si vous installer un MS-Windows en RAID. Ceci ne sera pas abordé dans ce billet qui est déja suffisement long comme ça.

La route est droite mais la pente est RAID

Il y a différentes façons d'envisager le RAID.

RAID matériel

Le RAID matériel se matérialise (haha) sous la forme d'une carte d'extension qui supportera des disques SCSI , IDE ou SATA.
Les disques sont reconnus dès le boot par la carte, et le support est transparent pour l'OS qui verra les disques tels que le controleur RAID lui présente.
Pas de bol, c'est souvent associé à du matériel bien propriétaire, avec des disques bien spécifiques. Malheur à vous si vous osez utiliser un disque qui n'est pas absolument identique!
Bien entendu, les disques de votre array ne seront plus disponibles à la vente au moment où ils auront besoin d'être remplacés.
Les processeurs sont aujourd'hui largement plus puissants que les chipsets intégrés des cartes RAID (sauf cartes couteuses pour usages bien spécifiques, voir ci-dessous).
N'espérez pas récupérer vos disques avec un controleur RAID différent de celui d'origine.
Bref, aucun intêret, si ce n'est pour des cas bien spécifiques. Par exemple, dans le cas de grosses unités RAID montées sur une dizaine de disques. Le bus de la carte RAID sera plus efficace.
En réalité, le seul intêret est que le RAID matériel rassure le windozien, pour qui le RAID logiciel évoque la prise en charge foireuse par le bios buggé de sa carte mère Asuxxtoc. Le pauvre homme.

RAID logiciel

Pas besoin de matériel coûteux.
Le kernel Linux est tout a fait adapté au RAID logiciel, et la mise en oeuvre ne pose pas de problèmes particuliers.
On peut mélanger les disques (différents modèles ou constructeurs).
- C'est même mieux de procéder ainsi, car on considère que les disques de même série vont avoir tendance à tomber en panne... en même temps. C'est d'ailleurs ce qu'on appelle la loi des séries.
On peut également mélanger différentes interfaces. Pour mon test, j'avais un disque en IDE, et deux en SATA. (je vous rassure, en prod c'est fait proprement. Les budgets pour la recherche, ce n'est plus ce que c'était, ma bonne dame.)
Vous n'êtes même pas obligés d' utiliser des disques de même taille. Il faut bien sûr qu'ils aient une taille suffisante pour contenir la/les partition(s) RAID.
En résumé, le RAID logiciel est tellement mieux pour les serveurs (je ne parle pas des grosses fermes de disques) qu'à part pour les fatigués de naissance et les pusillanimes, il s'impose de lui même.

Arch : mise en place d'un RAID logiciel

Situation de départ

Vous avez trois disques qui n'ont jamais servis, et vous souhaitez installer une machine sous Arch.
Il faut donc commencer par s'occuper de la mise en place du RAID.
Vous venez de booter sur le CD d'installation de Arch, et le curseur de la ligne de commande clignote impatiemment…

Partionnement

Vous pouvez utiliser cfdisk pour partitionner votre disque, en général disponible par défaut lors des installations.

Voici mon schéma de partionnement, avec trois disques sata (sda,sdb,sdc) :
- sd[a-c]1 : /boot (agrégé en raid1, partition bootable)
- sd[a-c]2 : / (agrégé en raid5)
- sd[a-c]3 : swap (non agrégé, hors raid)

Note: la partition /boot sera marquée avec le flag bootable sur chacun des disques.

Pas la peine de faire trois fois de suite un cfdisk avec les mêmes paramètres.
- Partionnez le premier disque, puis copiez le partitionnement sur les deux autres (assurez-vous d'opérer sur des disques vides).
- Avec sfdisk (et non plus cfdisk), nous allons dupliquer les données.
- sfdisk -d /dev/sda > partitions : pour dumper les infos de partitionnement.
- sfdisk /dev/sdb < partitions : pour écrire sur le second disque le partitionnement du premier.
- Vous pouvez vérifier le partitionnement: fdisk -l /dev/sd[a-c]

Pour info, le dump est une simple description ascii:


[root@archiso arch]# sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=       63, size= 48821472, Id=83, bootable
/dev/sda2 : start= 48821535, size=923833890, Id=83
/dev/sda3 : start=972655425, size=  4112640, Id=82
/dev/sda4 : start=        0, size=        0, Id= 0

création des arrays

Nous utilisons mdadm, couteau suisse du Raid.
La lecture de sa manpage n'est pas conseillée, elle est obligatoire.

Pour créer une array en RAID-1 (partition /boot):


mdadm --create /dev/md1 --level=1 --raid-devices=3 /dev/sda1 /dev/sdb1 /dev/sdc1 --metadata=0.90

Pour créer une array en RAID-5 (partition /) :


mdadm --create /dev/md2 --level=5 --raid-devices=3 /dev/sda2 /dev/sdb2 /dev/sdc2

Pour vérifier que tout s'est bien passé, deux possibilités:
- cat /proc/mdstat : le strict minimum.
- Pour avoir plus de détails:


~# mdadm -q --detail /dev/md[1-2]

Dans tous les cas, vous allez voir que les différents disques sont en train de se synchroniser, sauf si vous avez créé des arrays minuscules (dans ce cas, il y a des chances pour que ce soit déja fini).

Un exemple de sortie de /proc/mdstat pendant la reconstruction de l'array en RAID-5 (un gros morceau):


Personalities : [raid1] [raid6] [raid5] [raid4] 
md2 : active raid5 sdc2[3] sdb2[1] sda2[0]
      923833728 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
      [=>...................]  recovery =  9.1% (42417280/461916864) finish=64.2min speed=108744K/sec
      
md1 : active raid1 sdc1[2] sdb1[1] sda1[0]
      24410624 blocks [3/3] [UUU]

Vous pouvez bien sûr utiliser votre RAID pendant la reconstruction (sinon, le RAID n'aurait pas grand intêret).

Montage du RAID

A noter que cette partie pourra vous resservir hors installation, en cas de gros pépin par exemple.

Schéma du partitionnement RAID

Pour chacun des disques:
- sd[a-c]1 : /boot (agrégé en raid1 sur /dev/md1)
- sd[a-c]2 : / (agrégé en raid5 sur /dev/md2)
- sd[a-c]3 : swap (non agrégé, hors raid)

Assemblage des partitions RAID

Normalement, un modprobe sur les modules RAID n'est pas nécessaire (ces modules seront chargés lors de la première utilisation de mdadm).
- Au cas où, voici la liste des modules impliqués : md_mod et raid[456]

Avant de pouvoir mounter le RAID, il faut l'assembler (uniquement si vous venez de rebooter sur un système ne prenant pas encore en charge le RAID au moment du boot).


#Assemblage de la partition boot
[root@archiso ~]# mdadm --assemble /dev/md1 /dev/sda1 /dev/sdb1 /dev/sdc1
mdadm: /dev/md1 has been started with 3 drives.

#Assemblage de la partition home
[root@archiso ~]# mdadm --assemble /dev/md2 /dev/sda2 /dev/sdb2 /dev/sdc2
mdadm: /dev/md2 has been started with 3 drives.

Formatage des partitions

Rappel : md1 correspond à la représentation d'un disque complet.
- On peut rapprocher ce nom de device de sda , qui représente également la totalité du disque.

Ici, on veut utiliser le disque complet, donc on formate sans partitionner le device RAID. Exemple:
- mkfs.ext4 /dev/md1

attention au flag HUGE_FILE lors du formatage , il peut poser problème plus tard et est relativement inutile pour l'instant
- pour les problèmes possibles, voir la section premier boot.
- HUGE_FILE permet le support de fichiers de plus de 2 teraoctets (nous ne sommes pas prêt d'y arriver, tout comme 640Kb should be enough for everyone).

Montage des partitions.

Je n'ai monté que la première partition (root) qui servira à contenir le système.
- La partition "home" n'a pas d'intêret pour l'instant.


#Montage des partitions
[root@archiso ~]# mount /dev/md1 /mnt

Ajout du swap

Le swap est réparti sur les trois disques.

mkswap /dev/sda3 : à faire pour les 3 partitions.

On utilise la même priorité pour les 3 partitions de swap (avec -p 0)
- swapon -p 0 /dev/sda3 /dev/sdb3 /dev/sdc3

A noter que le swap n'est donc pas en RAID, donc en cas de claquage d'un disque, il peut se passer des choses bizarres. Le swap ne sert pratiquement plus de nos jours, mis à part pour l'hibernation. Je préférais vous prévenir afin que vous agissiez en connaissance de cause. Faites le chez vous les enfants, mais ne venez pas vous plaindre ensuite!

Installation et configuration du système

Il faut maintenant installer les paquets.
Dans le cas d'une Arch, il vous faudra au minimum base. Pour le reste, c'est vous qui voyez.
Ça y est ? Tous les paquets sont installés ?
Nous allons poursuivre la configuration en gardant à l'esprit que votre disque n'est pas encore à la racine, mais simplement mounté dans un tmpfs.

Création de la config mdadm


mv /mnt/etc/mdadm.conf /mnt/etc/mdadm.conf.old
mdadm --examine --scan >> /mnt/etc/mdadm.conf

Attention à bien écrire dans le /etc du mount, et non pas dans celui monté en RAM pour l'installation.

Gardez précieusement le fichier mdadm.conf original. Il vous servira plus tard pour compléter la configuration (adressse mail pour le monitoring, etc..)

le double >> pour la redirection dans mdadm.conf, c'est uniquement dans le cas où vous referiez la manip avec un fichier qui a déja servi.

Autres fichiers à éditer

Vous pouvez éditer ces fichiers depuis le menu d'installation de Arch.
- Il s'agit du menu "Install Packages".

Editez au minimum rc.conf pour avoir les locales en français au démarrage.

locale.gen : décommenter la locale choisie dans rc.conf

Si vous voulez utiliser un ramdisk pour charger les modules RAID (plutôt que de recompiler un noyau avec ledit support), c'est le moment de modifier: /etc/mkinitcpio.conf .
- mkinitcpio se lance depuis un environnement chrooté, mais Arch se charge fort bien de cette tâche lorsque vous quittez le menu d'édition des fichiers.

La configuration de pacman fera l'objet d'un billet à part.

N'oubliez pas de changer le mot de passe root.

Sortie de l'installeur

Vous pouvez quitter l'installeur.

N' installez pas Grub depuis le menu Arch. Nous allons le faire depuis le shell, dès que nous aurons chrooté le RAID.

Installation de GRUB

Chroot du RAID

Il nous faut maintenant chrooter pour continuer l'installation


[root@archiso ~]# mount -o bind /dev /mnt/dev
[root@archiso ~]# mount -t proc none /mnt/proc
[root@archiso ~]# chroot /mnt /bin/bash

GRUB sur le premier disque

L' opération est détaillée pour le premier disque.
- Elle sera à refaire pour chacun des disques, afin de pouvoir booter avec n'importe quel disque.

Nous installerons GRUB sur les autres disques après le premier boot.

Il nous faut commencer par ramener les fichiers de GRUB au bon endroit.
- cp -a /usr/lib/grub/i386-pc/* /boot/grub/

Un petit coup d'oeil à /boot/grub/menu.lst afin de nous assurer que les paramètres par défaut sont corrects...
- root est sur /dev/sda3. Ce qui est faux. Correction, avec remplacement par /dev/md1.
- Un autre problème que vous pourriez rencontrer: vous n'avez fait qu'une seule partition racine, avec /boot inclus dedans. Dans ce cas, le noyau est dans /boot, et non pas dans / .
- Voici ma config grub:


timeout   5
default   0
color light-blue/black light-cyan/blue

title  Arch Linux  [/boot/vmlinuz26]
root   (hd0,0)
kernel /boot/vmlinuz26 root=/dev/md1 ro md=1,/dev/sda1,/dev/sdb1,/dev/sdc1
initrd /boot/kernel26.img

Ensuite, nous invoquons grub avec ... grub

Et sous l'interface, nous rendons le premier disque bootable


grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Avant de rebooter

Assurez vous d'avoir changé le password de root, sinon vous ne pourrez pas utiliser ce compte.
Vous pouvez aussi créer un utilisateur : adduser -m toto puis passwd toto

Support par Linux au boot

Support par modules
- Par défaut, votre noyau de distrib a tous les drivers possibles compilés en modules (le noyau serait trop gros avec les drivers compilés en dur).
- Il faudra donc utiliser une image montée en ram juste après le chargement du noyau, pour utiliser les modules RAID.
- Je ne détaille pas cette option ici, mais j'ai préparé un billet que je posterai bientôt pour les gens intéressés.

Support dans le kernel
- Le plus facile est de se compiler un kernel avec le support RAID built-in.
- L'inconvénient est que l'on perd le noyau fourni par sa distribution. Sauf si bien sûr on crée un paquet avec le noyau nouvellement compilé.

Premier boot : alors ça, c'est RAID!

Montage en lecture seule des devices RAID (mdx)

Le boot semble bien se passer, tout va très bien Madame la Marquise ... sauf qu'on déplore un tout petit rien.
Les partitions md0 et md1 sont montées en lecture seule
- EXT4-fs (md0) : Filesystem with huge files cannot be mounted RDWR without CONFIG_LBDAF
Mais à part ça, Madame la Marquise, tout va très bien, tout va très bien.

Résolution 1 : bête et méchante.

Vous pouvez rebooter sur votre CD d'install, ré-assembler le RAID, et recompiler un noyau avec l'option CONFIG_LBDAF
- Cette option sert à supporter les fichiers de plus de 2 Tera-octets.
- Vu que mon RAID est composé de 3*40Go, ceci parait un peu inutile ... nous allons enquêter un peu plus sur ce message.

Résolution 2 : un poil de réflexion.

Nous allons inspecter les systèmes de fichiers (cette erreur ne concernant pas le RAID).

Reboot avec le CD d'install, et ré-assemblage du RAID. Mais cette fois, pas de recompilation du noyau!

tune2fs -l /dev/md1
- nous voyons le flag HUGE_FILE , qui provoque le problème.
- répéter l'opération pour md2 (normalement, c'est la même chose si vos partitions ont été créées de la même façon).

Nous allons enlever le flag HUGE_FILE
- tune2fs -O ^HUGE_FILE /dev/md1
- si nécessaire, répéter l'opération sur les autres unités RAID.
- vérifier que les opérations ont été répercutées (ex: tune2fs -l /dev/md1 )

Lancer un e2fsck sur les devices RAID (ex: e2fsck /dev/md1 )

Si tout est ok, reboot !

Dernières opérations après reboot

GRUB sur le disques supplémentaires

Il ne nous reste plus qu'à installer GRUB sur les disques restants, afin d'avoir trois disques identiques et substituables.

Relancez grub et tapez ces commandes:


grub> device (hd0) /dev/sdb
grub> root (hd0,0)
grub> setup (hd0)
grub> device (hd0) /dev/sdc
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Sauvegarde de la structure des disques

Afin de reconstruire rapidement un disque raid, il est utile de sauvegarder sa structure.
- Il faudra bien sûr un disque de taille identique ou supérieure pour restaurer.


 sfdisk --dump /dev/sda >sfdisk_sda
 sfdisk --dump /dev/sdb >sfdisk_sdb
 sfdisk --dump /dev/sdc >sfdisk_sdc

A mettre en lieu sûr. La partition raid devrait faire l'affaire.

Pour restaurer, il vous suffira de pratique l'opération inverse.
- sfdisk /dev/sda < sfdisk_sda

Base de monitoring

/proc/mdstat

On commence par utiliser les processus.
Pour l'admin, un cat /proc/mdstat suffit.
- ce n'est pas très pratique pour les scripts.

Le strict minimum peut être obtenu facilement:


cat /proc/mdstat | awk '/^md[0-9]/ { dev=$1 } /\[[U_]+\]/ { match($0,/\[[U_]+\]/,state); print dev ":" state[0] }'

à adapter selon ce que vous souhaitez en faire.
- par exemple, cette sortie pourrait être lue avec beuglement de la machine en cas de détection d'un disque en rade.

mdadm

On peut utiliser tout simplement mdadm.
- Il suffit de le placer en mode monitor.


mdadm -F -m toto@foo.com --scan -1 -t

Signification des flags:
- -F : mode monitor.
- -m : précise le mail où envoyer le rapport.
- scan
- -1 : une seule itération et sort (sans ce flag, lancé en daemon).
- -t

Pour recevoir des emails en cas d'alerte, vous avez un paramètre dans mdadm.conf:
- MAILADDR moi@bigcorp.com

RAID is dead (ou: RAID en rade)

Maintenant, simulons une panne afin de nous assurer que tout est d'équerre.

Où sont les disques ?

Pour commencer, il faut repérer les ports SATA pour retrouver les disques facilement dans le boitier.

Explorons un peu les devices pour retrouver tout ça:
- /sys/block/sda/device -> ../../../0:0:0:0
- qui pointe en fait vers
- /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0

Nous en déduisons:
- 1f.2 : controleur sata de sda.
- target : donne le port pour sda.

Pour faire plus court: readlink -f /sys/block/sda/device
- /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0

résultat de readlink sur sda, sdb, sdc :


sda: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
sdb: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:1/0:0:1:0
sdc: /sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0

Un coup d'oeil sur la carte mère..
- Sur l'epoxy de la carte mère, il est sérigraphié un libellé à côté de chaque port sata: sata-a, sata-b… jusqu'à sata-d pour ma part.
- Ces ports sont reliés à des disques. Une étiquette sur le cordon sata côté disque indique: hd0, hd1, hd2.
- Nous en déduisons assez logiquement que le nommage du controleur sata suit la même progression.

host0 pour les deux premiers, logique au vu du branchement physique.

Logique et Informatique ne riment que dans le dictionnaire.
- Nous pouvons vérifier notre théorie en débranchant le premier disque, machine éteinte.
- Ensuite, nous rallumons la machine en bootant sur le media d'installation ou sur un live-CD (surtout pas sur votre OS à ce stade!).
- Il ne reste plus qu'à vérifier, en faisant la manipulation ci-dessus. Vous devriez retrouver facilement l'emplacement physique du disque déconnecté.

Tout ceci devrait faciliter le remplacement d'un disque grillé, sans avoir besoin de l'horrible méthode essai/erreur.

Simulation d'une panne soft

Les possibilités ne manquent pas, avec option électrocution pour les aventuriers de tous les dangers.
- Pour commencer, j'ai choisi la méthode douce: marquage d'une partition raid en fail, et retrait de celle-ci.

Marquage en fail:


# mdadm -f /dev/md1 /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md1

Retrait de la partition:


# mdadm -r /dev/md1 /dev/sda1
mdadm: hot removed /dev/sda1 from /dev/md1

Vérification du retrait de sda1 de md1
- La première partition est arrêtée: _UU


# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sdb2[1] sdc2[2] sda2[0]
      923833728 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md1 : active raid1 sdc1[2] sdb1[1]
      24410624 blocks [3/2] [_UU]

Remise en route du raid
- Auparavant, nous créons un gros fichier sur md1, juste pour rire.
- dd if=/dev/urandom of=garbage count=1M bs=1K

Et nous ajoutons sda1 à l'array md1
- mdadm -a /dev/md1 /dev/sda1

Ça bosse ? Un petit coup d'oeil à mdstat


# mdadm -a /dev/md1 /dev/sda1
mdadm: re-added /dev/sda1

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid5 sdb2[1] sdc2[2] sda2[0]
      923833728 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md1 : active raid1 sda1[3] sdc1[2] sdb1[1]
      24410624 blocks [3/2] [_UU]
      [>....................]  recovery =  1.2% (293632/24410624) finish=2.7min speed=146816K/sec

unused devices: <none>

Simulation d'une panne hard

Cette fois, c'est du sérieux. Terminé les marquages fail, place au tournevis.
Éteignons la machine, et retirons le disque correspondant à sda.
Nous en plaçons un autre en remplacement.
- Nous avons vu plus haut comment repérer les disques dans le boitier.

Bien entendu, nous n'avons pas pu sortir proprement de l'array raid le disque grillé.
- Il faut donc rebooter sur un live CD, pour reconstruire l'array.

Pas de bol, le nouveau disque inséré est identifié comme étant sdb (les joies de udev).
- En situation critique, il faudrait donc au plus deux reboots (et les fsck afférents) pour trouver un disque grillé.

Dans mon test de restauration, le disque de remplacement avait une capacité très inférieure aux autres disques. Cela ne gêne pas pour du raid soft, et je me suis contenté de reconstruire la partition système.
- Opérons un fdisk sur un disque faisant partie de l'array, afin de récupérer les valeurs start et end de la ppartition système. Ensuite, nous re-créons la partition sur le disque de remplacement, en utilisant bien sûr les mêmes valeurs.
- Il y a encore plus simple: si vous aviez sauvé les valeurs de vos partitions raid avec sfdisk, vous pouvez faire l'opération inverse pour initialiser le nouveau disque (il faut cependant qu'il soit de capacité identique ou supérieure aux disques déja présents).

Une fois le disque de remplacement paramétré, nous pouvons assembler le raid.
- Nous commençons par intégrer les deux disques corrects.
- C'est un assemblage en mode dégradé (d'où le paramètre --run)


~# mdadm --assemble --run /dev/md1 /dev/sda1 /dev/sdc1

Normalement, nous obtenons: mdadm: /dev/md1 has been started with 2 drives (out of 3)
Un cat /proc/mdstat donne plus de précisions


md1: active raid1 sda1[0] sdc1[2]
     24410624 blocks [3/2] [U_U]

Il ne nous reste plus qu'à ajouter le disque de remplacement à l'array:


~# mdadm --add /dev/md1 /dev/sdb1
~# cat /proc/mdstat # indique que le recovery est en cours.

Le mount du disque RAID est possible, pour vérifier que tout est bien là.
- mount /dev/md1 /mnt

Attention à éditer mdadm.conf et /etc/fstab sur votre array, si vous n'avez pas restauré toutes les partitions!

Rebootons sur notre RAID remis en état.

Voilà.

Si vous avez fait un test et que vous désirez remettre l'ancien disque, enlevé uniquement durant le test:
- bootez sur un live CD.
- agrégez le raid sur les deux disques synchronisés dans le raid.
- ajoutez le disque (même procédure que ci-dessus).

Une astuce pour finir. Vous pouvez très bien faire:


#ici, /dev/sdb1 n'a pas encore été remis dans l'array

~# mdadm --assemble /dev/md1 /dev/sd1 /dev/sdb1 /dev/sdc1
mdadm: /dev/md1 assembled from 2 drives - need all 3 to start it
       (use --run to insist).

~# mdadm --run /dev/md1
mdadm: started /dev/md1

Un cat /proc/mdstat montre que sdb est manquant.
- Il ne reste qu'à ajouter sdb1 à md1, et c'est reparti!

Mais je serai RAID avant qu'il n'ait fini !

Vous avez sans doute remarqué que la reconstruction d'une array pouvait prendre un certain temps.
Heureusement, il y a moyen d'accélérer les choses.

Vous ne voulez rien synchroniser, car vous avez juste déplacé un disque de port SATA sur la carte mère. Ceci peut arriver dans le cas d'un changement de cable par exemple, cable qui sera trop court. Dans ce cas, votre troisième disque contient déja toutes les données et vous n'avez pas besoin de le reconstruire.
- ATTENTION cette option n'est valable que si vous n'avez pas encore monté le RAID que vous voulez reconstruire. Si vous avez booté sur le RAID ou monté vos disques RAID, c'est fichu, cette option n'est plus valable.
- Faites un resync du nouveau disque avec l'option ——assume-clean.

Un cas plus classique de grande lenteur.
- Dans un cas plus réaliste, c'est à dire si vous ajoutez un disque neuf, vous serez obligé de tout reconstruire. Mais même dans ce cas, vous pouvez également accélérer les choses.


~# cat /proc/sys/dev/raid/speed_limit_min
1000
~# cat /proc/sys/dev/raid/speed_limit_max 
200000

Ceci signifie que pour chaque disque, la limite minimale de reconstruction est de 1mo par seconde. Et la limite haute est de 200mo/s.
La limite basse est vraiment peu élevée. On peut l'augmenter.


echo 20000 > /proc/sys/dev/raid/speed_limit_min
 
OU
 
sysctl -w dev.raid.speed_limit_min=20000

Nous passons ainsi à un objectif de 20mo/s.
- Ces modifications sont temporaires. Il faudrait placer le sysctl dans un fichier de démarrage pour les rendre résistantes au reboot.

Nous disposons également de l'option bitmap, qui accélère la reconstruction.


~# mdadm --grow --bitmap=internal /dev/md0

Une fois l'array reconstruite, il faut désactiver l'option.


~# mdadm --grow --bitmap=none /dev/md0

Une autre option susceptible d'accélérer les choses est de mounter les partitions avec l'option noatime
- Cette option n'est pas spécifique au RAID, mais elle accélérera les transactions sur les partitions journalisées avec EXT4.
- fstab : /dev/md1 / ext4 defaults,noatime 0 1 (partition root)
- suivi d'un mount / -o remount
- puis d'un controle avec cat /proc/mounts

Un petit exemple de vitesse avec ces paramètres modifiés (speed_limit_min et bitmap):


~# mdadm --grow --bitmap=internal /dev/md1

~# mdadm -a /dev/md1 /dev/sdc5

# cat /proc/mdstat 

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md1 : active raid5 sdc5[3] sda5[0] sdb5[1]
      1718745088 blocks level 5, 512k chunk, algorithm 2 [3/2] [UU_]
      [>....................]  recovery =  0.5% (4840064/859372544) finish=150.8min speed=94402K/sec
      bitmap: 3/7 pages [12KB], 65536KB chunk

Better RAID than dead

Sur ce, j'arrête les jeux de mots faciles. Avant que tout cela ne ressemble au style des admins BSD.
Merci d'avoir pris le temps de lire ce long billet (oserais-je parler d'article ?). J'ai passé encore plus de temps à l'écrire.
Dernière chose: j'ai utilisé mes notes provenant de l'installation de deux machines. Il se peut que certains devices vers la fin ne correspondent plus à ceux du début. J'ai tout relu et corrigé, bien sûr, mais certains détails ont pu m'échapper.

RTFM

Jean-Seb — Tue, 15 Mar 2011 00:17:00 +0100

RTFM! Qui n'a jamais entendu cette injonction, tant laconique que définitive, à la suite d'une innocente question ?
Alors on lance man... et les pages de manuel s'accumulent dans les terminaux.
Mais il existe une solution.
Dans tous les moments de la vie, Vim est votre ami.

Apprendre à lire

man, classique

man est lancé depuis le terminal actif, puis fermé pour utiliser la commande.
- Bien entendu, juste après la fermeture, la moitié des paramètres est déja oubliée.

man, séparé

Vous utilisez un autre terminal, et vous lancez man au sein de celui-ci.
- Le terminal principal reste libre, et vous gardez le manuel ouvert à l'endroit qui vous intéresse.
- Cette façon de faire est un peu meilleure, mais les terminaux ont tendance à se multiplier, voire s'empiler (sous X).

man avec Vim

Vim possède depuis plusieurs années déja le support des tabs.
- Chaque tab correspond à une zone de saisie différente au sein de Vim.
- A ne pas confondre avec le mode splitté de la zone de saisie (:help split).
- Très pratique pour l'édition multiple de sources.

Pour tester les tabs:
- Lancez Vim.
- Et en mode commande: :tabnew

Pour avoir la liste de toutes les possibilités associées aux tabs:
- :help tabs

Nous allons utiliser les tabs afin d'ouvrir chaque nouvelle page de man dans un nouveau tab.

Contrôle de Vim à distance

Tout cela est bien beau...

Vous allez me dire (et vous aurez bien raison) que tout cela est bien beau.
Et vous ajouterez (toujours avec raison) qu'encore faudrait-il avoir la possibilité de contrôler une instance de Vim depuis le shell.
Comme vous vous en doutez, on peut. A la seule condition que Vim ait été compilé avec l'option clientserver
- Le paquet officiel de Arch comporte cette option. Utilisateurs Ubuntu, ne pleurez pas, vous bénéficiez du même traitement de faveur.
- Les vrais mecs sous Gentoo n'ont plus qu'à recompiler avec le bon flag. Quand aux Slackers, ils ont d'autres soucis: Pango vient de se téléscoper Cairo après une mise à jour douteuse, et plus rien ne fonctionne.

Vim! Lève toi et marche!

Il faut lancer Vim en mode serveur, avec un nom d'instance pour le repérer par la suite:
- Afin de bien appuyer le propos, finiderire est utilisé comme nom d'instance.
- vim --servername finiderire

Et ensuite, on ouvre un fichier dans l'instance finiderire.
- gvim --servername finiderire --remote-tab /etc/passwd

A noter l'option --remote-tab-silent qui ne provoquera pas d'avertissement de Vim si l'instance est créée en même que l'ouverture de la tab.
- Nous allons utiliser cette option pour notre pager, afin d'éviter de tester l'existence de l'instance pour la première ouverture.

Et pour tout voir sans rien payer:
- :help remote

Communication man/Vim

MANPAGER

$MANPAGER est une variable d'environnement du shell qui permet d'indiquer quel pager utiliser pour ouvrir une page man.
- Il faudra penser à l'initialiser avec le nom et l'emplacement de notre script, une fois celui-ci au point.

Pour le moment, nous lançons man avec l'option -P qui a une priorité supérieur à $MANPAGER.
- Pour avoir le comportement par défaut de man (ouverture dans le terminal de la page de manuel):
- man -P "less -s" ls

Les opérations à réaliser

On commence par récupérer la sortie de man avec un simple cat:
- man -P "cat " ls >/tmp/man.$$

Récupération de la page dans Vim:
- gvim --servername finiderire --remote-tab-silent /tmp/man.$$

Effacement du fichier temporaire:
- rm /tmp/man.$$

Script final

Voici un script plus complet.


#!/bin/bash

pageman=/tmp/$$.man

rm -f /tmp/*.man

cat | col -b -x > $pageman

man_asked=/tmp/"$(head -1 $pageman | sed 's/\(^[^\ \(]\+\).*/\1/')".man
mv "$pageman" "$man_asked"

gvim -R -c 'set ft=man nomod nolist nonumber guioptions="-T -m"' -font "Terminus (TTF) 12" -c 'map q :q!<CR>' --servername finiderire --remote-tab-silent $man_asked

Et voici les explications

Effacer les anciens fichiers man en entrée du script.
- On ne peut pas le faire en sortie du script, car il n'y aurait plus rien dans Vim.
- rm -f /tmp/*.man

Formatter la sortie de man.
- cat | col -b -x > $pageman

Récupérer le nom de la page de manuel demandée.
- Cela sert à générer le nom du fichier, afin d'afficher le nom de la commande dans la tab.


 man_asked=/tmp/"$(head -1 $pageman | sed 's/\(^[^\ \(]\+\).*/\1/')".man

Et le gros morceau: le lancement de Vim.
- passer en read-only : -R
- indiquer que le type de fichier est une page man, pour la coloration syntaxique: set ft=man
- diverses commandes pour désactiver les préférences du .vimrc : nomod nolist nonumber
- supprimer la toolbar et le menu pour gagner de la place: guioptions="-T -m"
- changer la fonte par défaut: font "Terminus (TTF) 12". Cette fonte est disponible dans les paquets Arch.
- permettre de quitter la page avec un simple appui sur la touche q : map q :q!<CR>. Et si vous modifiâtes par erreur le buffer, vous sortirez sans confirmation.
- Et enfin, ouvrir la page man dans l'instance finiderire, dans une tab portant le nom de la commande demandée.

N'oubliez pas d'ajouter dans votre .bashrc (pour les utilisateurs de bash, bien sûr)
- export MANPAGER=/path/vers/votre/script

Améliorations possibles

Dans ce script, j'utilise gvim, qui est la version X de Vim.
- Vim peut également être lancé avec ou sans l'option -g, selon que vous désirez ou non la version X.
- En d'autres termes, gvim est un alias pour vim -g
- Vous pourrez donc modifier le script pour lancer en mode console vim, et passer en mode gvim si l'environnement graphique est détecté.

Une autre amélioration possible serait de nommer les tabs sans l'astuce du mv.
- Vous pouvez initialiser Vim en précisant le nom du tab : :help setting-guilabel.
- C'est d'ailleurs la façon la plus propre de procéder. Je n'ai découvert cette possibilité qu'après avoir écrit le script, à la relecture de ce billet.
- Cette modification est donc laissée à titre d'exercice au lecteur.

Une modification sympathique serait d'intercepter le double clic de la souris, qui surligne un mot sous Vim, afin de lancer la page man correspondante.
- Vous pouvez bien sûr d'ores et déja faire :!man foo depuis Vim pour ouvrir la manpage foo.
- Il serait cependant plus agréable de le faire d'un simple (double) clic.

RTFM, RTFB

Si d'aventure vous goûtez au RTFM! sur un forum, consolez-vous en pensant que ça arrive même aux meilleurs.
- Et si vraiment vous êtes vexé, consolez-vous en pensant que vous avez désormais le plus beau pager de la galaxie pour lire les pages man.

Voilà.

Et n'oubliez pas, RTFB !
- Read The Finest Blog, bien entendu.

Unison : o c mal

Jean-Seb — Wed, 08 Dec 2010 22:43:00 +0100

Les habitués de mon blog et de ma rigueur langagière doivent déja frémir en voyant ce titre !
Est-il devenu fou ? Le blog a t-il été piraté ? Cède t-il aux sirènes du jeunisme triomphant ?
Nenni ma foi, et je ne puis que vous encourager à poursuivre.

Justifications

De l'origine d'Unison

Unison est écrit en OCaml, langage fort respectable à mi chemin entre le procédural et le fonctionnel.
La communauté OCamlienne est pour l'essentiel française. Elle se situe pour la plupart dans les locaux de l'INRIA. Elle communique en anglais via le channel IRC éponyme sur Freenode.
OCaml est pour le moment en phase de transition majeure. Le temps que les platres soient essuyés, méfiez-vous de la version 3.12 .
Par ricochet, Unison recontre quelques problèmes (distribution Arch Linux) avec OCaml. D'où le titre.
- A noter que ce problème ne touche pas Gentoo. Utilisateurs de Arch, continuez à lire. Utilisateurs de Gentoo, continuez à compiler.
- En fait, ça fonctionne sous Gentoo car OCaml 3.12 n'est pas encore en stable dans portage, donc les problèmes ne sont pas encore apparus.

Description des symptomes

Unison existe en trois versions, du moins sous Linux:
- texte (pratique pour tester, mais peu agréable à l'usage).
- gtk (moche).
- gtk2 (la version par défaut).

La version texte fonctionne toujours, c'est celle à privilégier pour vérifier le bon fonctionnement d'une connexion distante.

Le sujet a déja été abordé dans ce fabuleux blog, rappelons simplement que la communication peut se faire en clair ou avec SSH.

Le script qui esquive le problème

Unison va devoir être lancé via un script

Contenu du script:


~$ cat ./unison2.32
mon_host=desktop_jseb_arch
unison_local=unison-gtk2
#unison_local=unison-gtk

echo "lancement de Unison avec ces paramètres :"
echo "UNISONLOCALHOSTNAME=$mon_host $unison_version"
UNISONLOCALHOSTNAME=$mon_host ltrace -L $unison_local -servercmd=unison-2.32 -contactquietly

Quelques explications

Le "contactquietly" permet d'avoir le focus sur le terminal, plutot que sur une inutile boite de dialogue.

Le patch de Jérome Vouillon

https://bugs.archlinux.org/task/20877?getfile=5824
- J'ai eu du mal à le trouver, je le joins en fichier à ce billet par précaution.

Soyons fou, à l'unison

Si ça continue, je vais créer un tag Unison.
Et assurer le SAV également.

Chauds les marrons! La duplication sans chataignes

Jean-Seb — Wed, 24 Nov 2010 19:48:00 +0100

Vous avez installé Linux sur un disque, tout est bien configuré, et parfait dans le meilleur des mondes.
Seulement voila: vous avez décidé de répliquer votre installation sur un plus gros disque. Ou pourquoi pas, un plus petit (SSD).
Contrainte supplémentaire: vous voulez le faire à chaud, pour bénéficier de votre environnement (et continuer à surfer pendant l'opération).

La grande réplication

Ce que nous avons

Un disque dur /dev/sda avec deux partitions ext4, et une partition swap.
- Les partitions ext4 contiennent respectivement / et le contenu de /home.
- La partition swap est utilisée pour l'hibernation.

Ce que nous voudrions que cela devienne

Nous venons de monter un second disque dur, reconnu comme /dev/sdb
- Ce disque va servir à répliquer le premier disque dur.
- Il est partitionné avec deux partitions ext4, et une partition de swap.
- Ses partitions n'ont bien sûr pas la même taille que le premier (le but n'est pas de faire une réplication à l'identique, mais bien de gagner de la place!).

En résumé

Nous voulons copier sda vers sdb.
- sda1 = /
- sda2 = /home

Procédons !

Nous venons de booter sur le disque servant de base à la réplication (sda).
- Pour l'instant, sdb ne contient rien (je pars toutefois du principe que fdisk est déja passé par là).

Formatage des partitions sur sdb


mkfs.ext4 /dev/sdb1 -L arch_root
mkfs.ext4 /dev/sdb2 -L arch_home

Il est important de nommer les partitions (argument -L), car cela permet ensuite de se passer des noms de devices.
- fstab utilisera les noms de partitions pour le mount.

Montage des partitions de destination


mount /dev/sdb1 /media/hd
mkdir /media/hd/home
mount /dev/sdb2 /media/hd/home

A adapter selon vos goûts (et votre schéma de partitionnement) bien entendu.

Re-montage de la partition système en cours d'utilisation

Pourquoi re-monter une partition forcément déja montée, puisqu'en cours d'utilisation ?
- Parce qu'on ne peut pas faire un cp -a / /media/hd directement.
- En effet, il y aurait copie récursive lorsque cp arriverait sur /media/hd du premier disque.

Il faut donc remounter / avec:


mount -o bind / /mnt/root

le but du mount -o bind est de donner accès a la partition root brute (sans aucun mount, ni /proc monté).
Elle reste bien sûr montée sur / par ailleurs (fort heureusement).

La copie peut débuter


cp -a /mnt/root/* /media/hd/

Comme dit précédemment, ça ne copie pas /home. Il est toujours monté à son emplacement d'origine.

Nous allons donc le copier à son tour.


cp -a /home/* /media/hd/home/
(puis, eventuellement:)
chown jseb.jseb /media/hd/home/jseb

Cooooopie, c'est fiiiiini ...

Avant de démonter, nous créons un fichier à la racine du nouveau disque pour le repérer plus facilement dans grub.


touch /media/hd/nouveau_disque

Cette astuce va nous permettre de ne pas commettre d'impair avec grub.

On peut ensuite démonter les partitions.


umount /media/hd/home
umount /media/hd

Fignolagisation

Cet horrible néologisme qui raye l'émail n'avait que pour but de réveiller les lecteurs assoupis pendant la copie.
- En effet, tout n'est pas fini: nous voulons que ce disque soit bootable, et que l'hibernation soit toujours fonctionnelle.
Avez-vous vérifié que la partition destination système avait le flag bootable, au fait ?

fstab

Tout d'abord, occupons nous du fstab présent sur le disque de destination.
Si vous n'avez pas changé les noms et les emplacements de vos points de montage, vous pouvez laisser telles les entrée concernées.
Il vous faudra cependant au moins modifier l'entrée pour la swap, dont l'id va changer.
Vous devriez avoir quelque chose dans ce genre (j'ai isolé ce qui nous intéresse, le vrai fstab est plus long):


LABEL=arch_root / ext4 defaults 0 1
LABEL=arch_home /home ext4 defaults 0 1
#pour monter automatiquement le swap d'après son UUID (et non plus le premier trouvé dans l'ordre d'énumération des devices)
UUID=5e6d9679-16dc-48f7-889b-2c7181c01e15 swap  swap defaults          0      0

Quelques explications à propos du swap et son identification par l'UUID.
- Si on reboote avec l'ancien disque branché, et que le swap n'a pas été précisé dans la config, le premier trouvé (quel que soit le device) sera utilisé.
- On ne peut pas utiliser les lettres de device (sda, sdb ..) pour indiquer où se trouve le swap, car le nommage est dynamique et ne tombera pas forcément sur le device précisé dans la config.
- Il faut utiliser l'UUID de la nouvelle partition de swap, obtenu avec "mkswap".
- Si vous n'avez pas noté l'UUID du disque au moment de la création du swap, vous pourrez le retrouver ici: /dev/disk/by-uuid

Configuration du pingouin gelé

Les fichiers de configuration de TuxOnIce se trouvent généralement ici: /etc/hibernate/

Dans tuxonice.conf, vous devriez ajouter l'uuid de votre nouveau swap.
- Ceci évitera l'utilisation du swap de votre ancien disque, si celui-ci est trouvé en premier.


SuspendDevice swap:UUID=5e6d9679-16dc-48f7-889b-2c7181c01e15

Ne modifiez pas l'emplacement du swap pour l'hibernation dans la configuration du kernel, cela ne concerne pas TuxOnIce.
- Donc pas la peine de recompiler un noyau.

grub

Contenu potentiel de menu.lst


# /boot/grub/menu.lst:

title  2.6.36-ToI JSeb
root   (hd0,0)
#kernel /boot/vmlinuz26 root=/dev/disk/by-label/arch_root ro VGA=ask
kernel /boot/vmlinuz26 root=/dev/disk/by-label/arch_root ro resume=swap:UUID=5e6d9679-16dc-48f7-889b-2c7181c01e15 VGA=ask
initrd /boot/kernel26.img

On remarquera que le root pointe sur mon premier disque.
La copie s'est faite vers sdb (dans l'ordre des énumérations).
- Ce n'est pas grave: sdb devient tout simplement sda.
- Vu que les devices ne sont pas utilisés dans la suite du boot (repérage par nom de partition et par UUID pour le swap), tout fonctionne.

Ensuite, lancez grub en root.


grub> find /nouveau_disque
 (hd1,0)

grub> root (hd1,0)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd1)

A noter l'astuce du find, sur le fichier précédemment créé à la racine.
- Ceci permet de repérer à coup sûr le disque.

Voila, grub est installé sur le MBR.
- pour installer sur sdb1 , ce que certains préfèrent , il aurait fallu faire:
- setup (hd1,0)

C'est dans la boite

Que dire de plus ?
reboot ! Et croisez les doigts, on ne sait jamais.

Arch, le kernel et la marmotte

Jean-Seb — Thu, 11 Nov 2010 19:34:00 +0100

Vous venez de compiler un noyau personnalisé pour votre Arch.
Vous pourriez le copier à la main - et perdre le suivi de version des paquets Arch.
Que fait la marmotte avec le beau noyau de Arch ?
Elle l'emballe dans le paquet!

La saison des marmottes

kernel perso

Nous voulons donc nous compiler un noyau personnalisé, et l'empaqueter proprement.
Afin d'ajouter un peu d'intérêt à la chose, nous allons aborder un cas que les noyaux génériques de Arch ne couvrent pas.
- Il s'agit d'ajouter au noyau le patche TuxOnIce, afin de permettre l'hibernation.
- Dans AUR, il y a bien un build s'occupant de cette tâche. Il ne fonctionne hélas pas du tout. Je vous laisse vous référer aux rapports de bugs Arch pour plus de précisions (c'est à dire que vous apprendrez qu'il est urgent d'attendre une nouvelle version du noyau).
- Les impatients devront donc compiler eux-même leur noyau. C'est ce que nous allons faire, et nous en profiterons au passage pour expérimenter une ou deux nouvelles pratiques.

Vous avez tous une carte 3D ? Sous Linux, NVidia est malheureusement le passage obligé. Nous ajouterons donc la création d'un paquet contenant les derniers drivers propriétaires.

Dans ce billet, je n'aborde que les grandes lignes des manipulations générales, et je n'entre dans les détails que pour les spécificités Arch.
- Par exemple, si vous ne savez pas patcher les sources du kernel avec TuxOnIce, lisez la documentation du site web du projet.

Et la marmotte ?

Je viens de voir passer la marmotte, et elle trainait un gros édredon. Il ne va pas falloir trop compter sur elle.
En d'autres termes, vous allez devoir faire le paquet vous même.

Préparation

Récupération des sources

Récupérez le dernier noyau stable sur kernel.org.
- Pour l'instant, il s'agit du 2.6.36.
Les sources sont placées dans /usr/src.
- Certaines personnes vous diront de les mettre dans votre home. Ignorez les.
N'oubliez pas de faire un lien symbolique /usr/src/linux pointant vers votre répertoire de sources kernel.
- ln -s linux-2.6.36 linux

Récupérez le patch de TuxOnIce, et placez le dans le répertoire du kernel à préparer.

Configuration du kernel

Commencez par patcher le kernel avec TuxOnIce.
- patch -p1 < tuxonice.patch

Supprimez les reliques et scories éventuelles. A faire même si vous venez de désarchiver les sources.
- make mrproper

Ensuite, il s'agit de choisir soigneusement les options du noyau (n'oubliez pas l'hibernation, ça serait bête)
- make menuconfig
- Si vous voulez hiberner en utilisant le swap, pas la peine de préciser l'emplacement de celui-ci dans les options touchant à l'hibernation du kernel (cela ne concerne pas TuxOnIce, mais le support interne du noyau pour l'hibernation. Son utilisation est déconseillée.).
- La configuration part dans les fichier .config, qui est effacé à chaque make mrproper. N'oubliez pas de le sauver sous un autre nom, on ne sait jamais.

Définition du paquet Arch

makepkg utilise deux fichiers de configuration, qui seront nommés ainsi pour l'occasion:
- PKGBUILD : pour la construction du paquet.
- kernel26.install : pour l'installation du paquet.

J'ai repris les deux fichiers du wiki Arch (mes modifications sont mineures) :
- un peu de lecture qui ne fera pas de mal

PKGBUILD

Vous n'aurez pas grand chose à modifier.
- En fait, je n'ai modifié que le nom du paquet, et le numéro de version du kernel.


pkgname=kernel26-jseb
basekernel=2.6.36
pkgver=2.6.36

kernel26.install

J'ai simplement changé ces deux lignes:


KERNEL_VERSION="2.6.36"
LOCAL_VERSION=""

Compilation

Pour les sensibles avec plusieurs coeurs

Si vous avez un processeur multicoeur, ne lancez pas directement makepkg .
- Faites plutôt un make -j n+1 , où n est le nombre de cpu disponibles (qu'il s'agisse de CPU physiques, de cores, ou de threads).
- Par exemple, pour un quad-core classique: make -j 5.
- pour un Xeon 5520 (quad-core, deux threads par core): make -j 9.

Les insensibles peuvent commencer ici

Lancez makepkg qui va créer le paquet.
- Si vous avez préparé la compilation comme décrit ci dessus, ça sera rapide: GCC n'aura plus qu'à linker les fichiers objets.
- Dans le cas contraire, il faudra être plus patient. Mais si vous n'avez pas inclus n'importe quoi dans le noyau, la compilation ne devrait pas dépasser dix minutes.

Installation du noyau

pacman -U chemin/du/paquet/kernel-bidule.xz
Ajoutez à la config de grub une entrée pour votre nouveau noyau, puis rebootez.
Ca boote encore ? Parfait!

Test de l'hibernation

Vérifiez que l'hibernation fonctionne depuis la console:
- n'oubliez pas d'installer le script d'hibernation si ce n'est déja fait:
- pacman -S hibernate-script

Après vous être assuré que la méthode employée est bien le suspend2disk, vous pouvez lancer la commande hibernate.
- Je ne détaille pas non plus la configuration de TuxOnIce, la doc est fort bien faite et il n'y a pas grand chose à raconter.
- Assurez-vous toutefois d'activer la compression.
- Si vous utilisez le swap pour le suspend2disk, plus besoin de préciser l'emplacement en paramètre du noyau, dans grub.

Il ne reste plus qu' à installer le driver nvidia pour pouvoir lancer X.

Haine vidia

Les drivers proprios nvidia, c'est toujours un grand moment d'émotion.
- Ne nous plaignons pas, ils fournissent des drivers corrects, eux (suivez mon regard, je ne vise personne).

Simplifions-nous la vie

Pour éviter d'y passer trop de temps, je me suis contenté de récupérer le build de nvidia-ice (situé dans AUR).
- yaourt -G nvidia-ice

Il n'y a pas grand chose à modifier dans PKGBUILD :
- la version du kernel.
- les dépendances : j'ai enlevé la dépendance sur le kernel, mais j'aurais pu tout aussi bien modifier le nom. Votre avis peut varier.


#!# pkgname=nvidia-ice
pkgname=nvidia-jseb

#!#_kernver='2.6.35-ice'
_kernver='2.6.36'

 (...)

#!#depends=("kernel26-ice" "nvidia-utils=${pkgver}")
depends=("nvidia-utils=${pkgver}")

Même principe pour nvidia-ice.install : modifier la variable KERNEL_VERSION si nécessaire.

Je voudrais vous en dire plus, mais j'ai effacé mon répertoire de build après avoir déplacé le paquet (un réflexe idiot).
- Je pense toutefois qu'il n'y avait pas grand chose de plus à raconter.

Pour finir, lancez makepkg dans le répertoire contenant le pkgbuild.
- Si tout s'est bien déroulé, vous avez un magnifique paquet nvidia prêt à être installé avec:
- pacman -U votre_driver_nvidia.xz

Test final (préparez l'oreiller)

Vous devriez maintenant être sous X.

Une console root, un hibernate ...

C'est terminé. Et ça marche!

Retirons-nous sur la pointe des pieds, afin de ne pas réveiller la marmotte qui a commencé son hibernation.

Back to the basic: un vent d'été de novembre

Jean-Seb — Fri, 05 Nov 2010 19:15:00 +0100

En ce moment, il fait chaud, et pourtant nous sommes début novembre.
Les bizarreries de la météo (blizzard, vous avez dit blizzard ?).
Celà m'a fait penser qu'il restait un article de cet été non posté.
Plutôt qu'attendre l'année prochaine, le voici.
Prenez celà comme le dernier soupir d'un bel été qui n'est plus que souvenir, avant la rentrée dans l'hiver froid, impitoyable, interminable! MUHAHAHAAAA!
MàJ 6 nov. 2010 : quelques précisions sur le partage de fichiers avec le système hôte.

Foin des considérations météorologiques

La dernière fois, nous parlions du développement sur vieux micro avec un cross assembler.
Cette fois-ci, pour nous reposer un peu, nous allons parler basic.
Mais oui, le basic : beginner awfully silly idiotic code. Enfin, un truc dans dans ce goût là.
Il y a vingt ans, les courageux précurseurs n'avaient souvent que ça à se mettre sous la dent.
Me croirez-vous si je vous dit que certaines personnes ne s'en sont jamais remises et continuent à le pratiquer ?
Afin de vous sensibiliser aux arcanes de ce qui touche désormais à la psychiatrie, je vous ai concocté une façon plus humaine d'aborder le problème.

OpenMSX members only

Attention, c'est pour OpenMSX, mais ça doit être transposable facilement à BlueMSX.
En fait, je suis même persuadé que BlueMSX est capable lui aussi d'écrire des fichiers dans le système de fichiers de l'ordinateur hôte.

Le basic MSX

tokens

Le basic du MSX est tokenisé. Quand on sauve un programme basic, les instructions apparaissent sous la forme d'un code hexa, qui représente une instruction. C'est ce qu'on appelle un token.
Cela permet de gagner de la place dans le fichier et en mémoire.

On peut sauver depuis le basic un fichier au format ascii (c'est à dire sans les tokens), avec:
- save "foo.bas",a

Le ",a" est important, c'est ce qui signale qu'on veut de l'ascii.
- Autrement, on n'aurait qu'une bouillie binaire représentant les tokens.

Pour le charger, toujours depuis le basic bien sûr:
- load "foo.bas"

Création d'un programme basic en dehors du MSX

On peut donc charger des fichiers ascii contenant des instructions basic.
- Attention à ne pas oublier les numéros de ligne quand on tape le programme dans un éditeur externe!

Il faut que les lignes se terminent par le CR/LF propre à MS-Dos.
- Le jeu de caractère ne doit pas être trop évolué (pas d'UTF-8). Latin1 fait l'affaire.
Si vous tapez vos sources depuis MS-Windows, pas de problèmes de ce côté là, cet OS fait partie de la famille des CR/LF. En digne héritier de MS-Dos.
Si vous utilisez un OS de conception plus moderne (Unix sous toutes ses saveur par exemple) il faudra convertir vos LF en CR/LF.

Voici l'automatisation de la manoeuvre pour Vim, l'éditeur des gens qui font pas semblant. Ajoutez ceci dans le .vimrc :


autocmd BufNewFile,BufRead *.[Bb][Aa][Ss] set ff=dos fileencoding=latin1

Ceci fonctionnera avec les fichiers qui ont une extension ".bas" (peu importe la casse, il y a la regexp pour ça).
Les fichiers seront automatiquement sauvés avec le format de fin de ligne MS-Dos, et dans un charset que le MSX comprend.

Communication simplifiée avec le système hôte

Les utilisateurs d'émulateurs se compliquent souvent la vie avec tout un système d'émulation de disquettes ou de disque dur.
Le plus simple (quand la machine et l'émulateur le permettent, ce qui est le cas ici) est de partager ses fichiers avec le système hôte.

Par exemple, pour partager /home/jseb/msx/coding avec le msx émulé :


openmsx -machine nms8245 -diska /home/jseb/msx/coding

La commande files depuis l'écran de saisie basic du MSX permet de lister les fichiers partagés entre le système hôte et le MSX émulé.
- Toutes les manipulations de fichier habituelles sont bien sûr possibles depuis le msx (load, save , bload ...)

Le paramètre machine nms8245 est là car je n'utilise pas tout le temps la même machine, et qu'il n'y en a pas de configuré par défaut.
- Selon votre configuration, vous pouvez vous en passer (si le cbios démarre par défaut, vous n'avez pas de machine de configurée).

L'utilitaire diskmanipulator de OpenMSX est à réserver aux manipulations d'iso de disquettes.
- Il est idéal pour transférer les fichiers vers un vrai msx, et s'utilise depuis la console d'OpenMSX.

Les numéros de lignes

Reste le problème des numéros de lignes pour le basic.
Ces vieux basic imposent une référence permanente aux séquences d'instructions. Cette référence est symbolisée par des numéros de lignes, sans autre rêgle qu'une progression constante et croissante.
Taper du code en commençant chaque ligne par un numéro croissant, c'est pénible.
- Sans parler des erreurs de renumérotations!
- Et que faire quand on n'a plus de numéros de lignes disponibles, et qu'on voudrait encore insérer une ligne dans cet ensemble ?

Le script magique

Voici un script qui permet de numéroter un programme basic de 10 en 10.
Les lignes commençant avec un numéro de ligne sont renumérotées, et quand il n'y n'y a pas de numéro de ligne, il est ajouté. En prime, les espaces et tabulations inutiles de début de ligne sont supprimées.
Les lignes vides sont ignorées.
Les références à des lignes existantes sont bien sûr traitées, sous réserve que les lignes référencées soient déja numérotées.
- On peut donc se contenter de numéroter ces lignes uniquement lors de la saisie.
- Le cas de "on k goto" suivi de plusieurs numéros de lignes est traité.
Les cas de lignes contenant des sauts multiples est traité.
- On peut en effet rencontrer des constructions barbares de ce type:
- gosub 20 : goto 10
- Beurk certes, mais le cas est géré.

Attention, si vous utilisez MS-Windows: vérifiez vos terminaisons de lignes pour éventuellement adapter le script si vos outils écrivent un 0xD 0xA comme terminateur. Ceci dépendra des choix par défaut de votre environnement d'origine: depuis un shell émulant Unix, ou depuis un programme utilisant directement l'api MS-Windows.


#!/bin/bash
# ce script vient de www.finiderire.com
# le blog pour les gens qui en ont dans le chausson.

if [ x"$1" == x"" ]; then
   echo $0 "[fichier à renuméroter]"
   exit 1;
fi

#simple précaution, un accident est très vite arrivé
cp "$1" "$1".bak 

#conversion au format Unix \n (Dos \r\n pose problème à awk)
#également, espacement des nombres séparés par virgule (cas de "on goto")
sed 's/\r$//;s/\([0-9]\)\ *,\ *\([0-9]\)/\1 , \2/g' < "$1" > "$1".tmp
mv "$1".tmp $1

#pour l'astuce de la relecture du fichier, voir awk/multipass.awk
awk 'NR!=FNR && !reset { l=0; reset=1; } #renumérote de zéro (2nde passe)

     #enlever espaces et tabs de début de ligne, si pas de numérotation
     NR!=FNR { sub (/^[\t\ ]+/,"",$0) }

     #renumérotation des goto/gosub (la seconde passe sert à ça)
     NR!=FNR && tolower($0) ~ /.*go(to|sub).*/ {
        for (i=1; i<=NF; i++) {
           #si pattern go(to|sub) détecté, prochaine colonne est un nbr
           if ($i ~ /.*go(to|sub).*/) { next_is_nbr=1 }
           # si on avait un goto/gosub juste avant ...
           if ($i ~ /[0-9]+/ && next_is_nbr) {
              $i = t[$i] #récupère index sur nouveau label
              if ( $i == "" ) $i="NaN" #si problème
              if ( $(i+1) != "," ) next_is_nbr=0; #cas de "on k goto ..."
           }
        }
     }

     #passe 1 et 2, on doit numéroter à chaque fois.
     /^[0-9]+/ { #un numéro de ligne est présent
     if (l || l==0) {l+=10} else {l=$1};
        l=l-(l%10);
        c=l;

      #par contre, on ne printe que lors de la passe 2
        if (NR!=FNR) {
           for (i=2; i<=NF; i++) { c=c " " $i; }
           print c
        } else {
        t[$1]=l; if ($1>max) max=$1
     }
    }
    

     /^[^0-9]/ && !/^\n?$/ { #pas de numéro de ligne, ni de ligne vide
        l+=10; l=l-(l%10);
        #on ne printe que lors de la passe 2
        if (NR!=FNR) {
          print l " " $0;
        }
       }


#    END { print "énumération"; for (i=0; i<=max; i++) print i " "t[i] }
    ' "$1" "$1" > "$1".tmp

#et on reconverti en \r\n, tout en supprimant les espaces désormais inutiles
sed 's/$/\r/;s/\([0-9]\) , \([0-9]\)/\1,\2/g' < "$1".tmp > "$1"
rm "$1".tmp

La compréhension du script est laissée à la sagacité du lecteur.
- Pour les lecteurs dont la sagacité s'agace, il y a les commentaires judicieusement placés devant ce qui mérite d'être commenté.

C'est la fin de l'été, mais pour le reste ?

Si vous en voulez encore, appuyez sur "commentaire" (1€ par appel).
Mais même si vous en voulez encore, je vous préviens qu'il vous faudra être fort.
- Le manque de temps fait que je risque de me concentrer sur des billets plus utiles pour les gens qui vivent dans la modernité.
- Et oui... finiderire pour les vieux trucs. Rendez-vous aux prochaines vacances !
Si vous avez simplement quelque chose à ajouter, ne vous privez pas. Et fermez la porte en partant, le temps commence à fraichir.

Git tari ? Oh!

Jean-Seb — Sun, 03 Oct 2010 21:46:00 +0200

Un nouveau billet sur l'intarissable Git
Et en avant la musique!
Note : cet article a été écrit en collaboration avec Frédéric Jolliton

Résumé de l'épisode précédent

La configuration et les commandes de bases de Git ont déjà été abordées.
- C'est ici que ça se passe

Cette fois, nous nous penchons sur l' utilisation de Git au quotidien.

repo sera l'abréviation de repository dans la suite du texte.

Déterrons le SSH de guerre

Vous voulez héberger un repo Git.
Si possible, vous souhaiteriez le repo Git hébergé ne nécessite pas un énième binaire troué et des heures de configuration ?
- Utilisez ssh, au moins il n 'y aura que ça à mettre à jour.

Vous ne le ferez qu'une fois

Créez un groupe git qui servira pour les droits d'accès de vos utilisateurs.
- groupadd git

Créez un home pour le/les repo(s) à héberger.
- mkdir /home/git

Modifiez les droits et les propriétaires.


boss # chown votrelogin.git /home/git
boss # chmod 770 /home/git

boss # ls /home/git -lhd
drwxrwx--- 3 jseb git 4,0K aoû 19 17:50 /home/git

Vous êtes le propriétaire de /home/git, et les utilisateurs abilités seront dans le groupe git.

Éditez le fichier /etc/shells et ajoutez une entrée avec l'emplacement de git-shell
- Ce fichier donne la liste des shells autorisés par le système.
- git-shell est un shell restreint qui permet uniquement l'utilisation de git.
- Les utilisateurs que vous créerez utiliseront ce shell.

A faire pour chaque utilisateur

Notre utilisateur sera le fameux toto.


useradd -d /home/git/ -G git -m -s /usr/bin/git-shell toto

-d /home/git : home de l'utilisateur.
-G git : il fait partie du groupe git.
-m : créer le home si il n'existe pas déja (et y copie /etc/skels/)
-s /usr/bin/git-shell : shell restreint de l'utilisateur.

Eventuellement, permettez à l'utilisateur d'utiliser ssh.
- Ce n'est pas obligatoire, et dépend de votre config sshd.
- sshd_config : AllowUsers toto

Si vous utilisez l'authentification interactive, n'oubliez pas de donner un mot de passe à votre utilisateur.

Faire un test de login.
- ssh doit vous envoyer paître.


$ ssh toto@192.168.1.1
Password:
Last login: Thu Aug 20 19:23:37 CEST 2009 from 192.168.1.42 on ssh
fatal: What do you think I am? A shell?
Connection to 192.168.1.1 closed.

C'est normal, git-shell ne permets pas ce genre de choses.

Création d'une repo bare

Une repo bare, c'est une repo dont vous ne verrez jamais le contenu directement.

Elle sert juste à distribuer des fichiers entre les utilisateurs.

Par exemple, les commandes checkout ne fonctionneront pas.

Côté serveur ssh

mkdir repo

cd repo

git init --bare


$ git init --bare
Initialized empty Git repository in /home/gitfoogit/

$ ls
config  description  HEAD  hooks  info  objects  refs

ls liste des fichiers qui sont normalement dans .git
Pas la peine de faire un git branch -a, il n'y a pas de branches.

Côté client


$ git remote add repo_remote ssh://jseb@192.168.1.1/home/git/repo

$ git push repo_remote mmap

On ajoute le serveur à la liste des repositories.
- Par la suite, on y fera référence sous le nom de repo_remote
- repo_remote est donc le nom du serveur (voir .git/config)

Une fois le serveur ajouté, on pushe les modifications.
- mmap est le nom de la branche que j'ai poussé sur le serveur.

Clonage par un utilisateur

Maintenant que les sources ont été pushées dans le repo, n'importe quel utilisateur peut y accéder.


$ git clone ssh://toto@192.168.1.1/home/git/repo
Initialized empty Git repository in /tmp/votre_repo/.git/
Password:
remote: Counting objects: 21, done.
remote: Compressing remote: objects: 100% (13/13), done.
remote: Total 21 (delta 7), reused 21 (delta 7)
Receiving objects: 100% (21/21), 432.15 KiB, done.
Resolving deltas: 100% (7/7), done.
Warning: Remote HEAD refers to nonexistent ref, unable to checkout.

Le repo est presque disponible pour toto.
- La dernière ligne indique qu'aucune branche n'est disponible.

Nous allons merger ce qui a été récupéré.


$ git branch -a
  origin/mmap

$ git merge origin/mmap

$ git branch -a
* master
  origin/mmap

La première commande récupère le nom de la branche qui a été clonée.
- origin est le nom par défaut du repo distant (voir .git/config)

La seconde effectue le merge.

La troisième vérifie qu'une branche est maintenant disponible.

Éventuellement, on peut renommer la branche master en mmap
- git branch -m master mmap

Le repo du guerrier

N'hésitez pas à poster vos méthodes et remarques, ainsi que tout ce qui concerne votre utilisation de Git au quotidien.

Il y aura surement d'autres billets sur Git, d'ailleurs je crée derechef le tag.
- Hop!

Vos plus belles recherches

Jean-Seb — Fri, 01 Oct 2010 20:48:00 +0200

Aujourd'hui, pour le bla-bla annuel, nous allons parler de vous.
Cela fait déja deux ans que le billet annuel m'est consacré, il est temps de changer.
Autrement, les mauvaises langues vont soutenir que ce blog ne parle que de moi.

Merci Google.

Mais comment parler de vous, mes chers visiteurs, alors que je ne vous connais que par les quelques commentaires récoltés sur mes billets ?
C'est bien simple, je vais m'inspirer des stats, et publier vos plus belles recherches Google.
Qui dit plus belles doit comprendre plus drôles. La majorité des recherches sont assez sérieuses, et bien dans l'esprit de rigueur de ce blog.
Mais il reste les perles, les OVNIs, les erreurs !

Nos grands gagnants par catégorie

Le puni.

requête : enlever cette version de Windows n'est pas authentique
commentaire
- Nous avons affaire à un apprenti pirate qui s'est complètement trompé de site. Ici, Monsieur, nous ne piratons pas Windows. Nous apprenons à nous en passer.
- A noter que la requête émanait de Bing, le moteur de recherche Microsoft. Peut être l'apprenti pirate a t-il été transféré ici en guise de punition ?

Le technicien de surfaces.

requête : recette du vim
commentaire
- Pour le coup, j'ai appris quelque chose. Vim n'est pas seulement le Meilleur Editeur du monde, mais également un produit nettoyant.
- La parité est loin d'être respectée sur Internet. Notre éditeur préféré a un net avantage dans les moteurs de recherche, et il faut surement être patient pour trouver la composition du produit de nettoyage.
- J'ai eu une typo dans une recherche, qui du coup devient amusante: ouvrir les fichier a la suie vim.
- Pour celui-ci, je peux répondre: vim toto.{c,h} puis :ball dans Vim pour ouvrir tous les buffers. Enfin, je suppose que c'est ce que voulait ce visiteur.

Le paranoïaque.

requete : test qui est ton ami
commentaire
- Ce blog est ouvert à tout le monde, sans distinction de sexe, race, religion ou famille politique.
- J'espère que ce visiteur à l'âme meurtrie aura trouvé réconfort et pardon en ces pages.

Le Jules.

requête : Je suis né pendant les ides de mars
commentaire
- Probablement une grosse déception pour le requêteur, qui est tombé sur mon billet à propos des IDEs (écrit en mars, d'où le titre complet).
- Il voudra bien pardonner mon humour un peu particulier, qui contribue à noyer le poisson de cette nouvelle Babel qu'est Internet.

L'enthousiaste.

requête : le disc wouah
commentaire
- Avec une faute d'orthographe en prime, mais nous pardonnerons volontiers un enthousiasme (presque) communicatif.
- Celà dit, je n'ai aucune idée de ce que pouvait bien chercher ce visiteur. Ni de ce qu'il a trouvé, d'ailleurs.

Le paradoxe.

requête : aucun texte ne s'affiche dans l'interface graphique
commentaire
- Encore un qui veut le beurre, l'argent du beurre, et la main de la cremière.

Le bricoleur.

requête : plomberie facile
commentaire
- J'ai régulièrement cette requête, qui amène vers un texte sur le traitement des fuites mémoires avec mtrace.
- Ces visiteurs ne reviennent jamais, sans doute morts noyés avant d'avoir eu le temps de faire une seconde recherche.

La valeur sûre.

requête : problème accents doxygen
commentaire
- Cette requête revient depuis bientôt trois ans. Elle fait partie des meubles, pour ainsi dire.
- Réjouissez vous, la réponse est dans ce blog. Je vous laisse admirer les lieux, prenez votre temps, et revenez me voir.

La récursivité en action

Pour conclure, j'espère que vous n'êtes pas arrivé sur cette page en faisant une des recherches citée dans ce billet.
Merci de votre visite, et à l'année prochaine pour un nouveau bla-bla.

Installation en milieu hostile

Jean-Seb — Thu, 23 Sep 2010 21:24:00 +0200

Certaines installations d'OS se font en milieu hostile.
Les réseaux au trafic douteux et à la sécurité incertaine ne sont pas qu'une légende pour vendre des abonnements à MISC.
Pourtant, les distributions Linux ont beaucoup de mal à s'installer sans connexion réseau.
AARRRHHH. Mais comment faire alors ?
MàJ 24/09/2010 : ajout astuce ip link

Pour qui ?

Ces notes ont été réalisées à partir d'une installation de Arch.
Linux proposant peu ou prou les mêmes outils de base dans ses différentes saveurs, vous devriez pouvoir adapter sans difficulté à une autre distribution.

Principe

Définir un réseau séparé

Vous placer sur un réseau séparé, c'est simple comme un ifconfig.
Là où tout cela se complique, c'est quand vous voudrez accéder à votre passerelle depuis le réseau séparé.
D'autre part, on voudrait quand même bien accéder à la machine en cours d'installation avec ssh.
Ces points légitimes étant soulevés, passons à la configuration du réseau alternatif.

Topographie

Nous avons une machine que nous souhaitons installer.
Nous avons une autre machine, déja installée et configurée, et avec une adresse réseau de prod. Cette machine se connectera en ssh vers la machine à installer. Elle servira également de passerelle internet.

Configuration

Mais où est eth0 ?!

Une petite astuce pour commencer : vous pouvez avoir pas mal de cartes réseau sur votre machine (4 pour ma part), et trouver celle qui a un cable branché peut devenir un casse-tête.
Un casse-tête, mais uniquement quand on ne connait pas la commande ip link . Haha! On fait moins le malin maintenant!

On commence doucement

Le principe est donc de créer un réseau séparé du réseau habituel, le temps de l'installation.
- Nous allons donc nous placer sur le réseau 192.168.42.0. La machine à installer aura l'adresse hote 42 :
- ip addr add 192.168.42.42/24 dev eth0

Ensuite, il faut intégrer la machine qui fera tourner le client ssh sur le même réseau.
- Cette machine va hériter de l'ip: 192.168.42.66
- Par ailleurs, elle est déjà présente sur le réseau habituel 192.168.1.0
- ip addr add 192.168.42.66/24 dev eth0 : l'interface réseau a maintenant deux adresses IP.

Tentez un ping d'une machine vers l'autre.
Ca fonctionne ? Bravo. Sinon, lisez la suite (de toutes façons, lisez la suite).

Ca se complique (très légèrement)

en cas de non réponse: vérifiez les paramètres de votre firewall (avec tcpdump).

Éventuellement, ajouter dans les rêgles du firewall de la passerelle:


 ## Pour la communication entre reseaux 192.168.42.0 et 192.168.1.0
  iptables -I FORWARD -s 192.168.1.0/24 -d 192.168.42.0/24 -j ACCEPT
  iptables -I FORWARD -d 192.168.1.0/24 -s 192.168.42.0/24 -j ACCEPT

 ## Pour rentrer sur la passerelle et acceder a ses services depuis le reseau 192.168.42.0
    iptables -A INPUT -i $INTERNAL_INTERFACE -s 192.168.42.0/24 -j ACCEPT

Connexion par ssh

Important

Sur la machine à installer (bien entendu) , changez le mot de passe root.
En cas de problèmes, n'oubliez pas de lire les logs, en particulier "auth.log".

configuration sur la machine à installer

Permettez le login root dans sshd_config , et l'authentification avec un password tunnelé:
- PermitRootLogin yes
- PasswordAuthentication yes

Ajoutez sshd:192.168.42.0/255.255.255.0 dans /etc/hosts.allow.

Lancez le daemon sshd.
- Sous Arch, on le lance comme ça:
- /etc/rc.d/sshd start

Connectez-vous avec ssh depuis la passerelle.

Passerelle et resolv.conf

Maintenant que la connexion ssh est prête, il n'y a plus qu'à ajouter l'accès internet.

Si la passerelle internet tourne sur la machine 42.66, c'est facile:
- ip r a via 192.168.42.66 dev eth0

Ajoutez également dans /etc/resolv.conf le(s) adresse(s) DNS.

Poursuivez l'installation

Maintenant, il ne vous reste qu'à continuer de manière classique l'installation.
La tâche de ce billet s'achève donc ici, tandis que la votre commence.

Ce sont les vacances: en avant toute vers le retro !

Jean-Seb — Tue, 24 Aug 2010 01:03:00 +0200

Eh oui, ce sont les vacances... enfin, il parait.
Et vu qu'il pleut, vous lisez ce blog au lieu d'aller à la plage.
Pire encore, vous lisez ce blog au bureau en pensant à vos collègues partis à la plage.
Réjouissez-vous, je vous ai mitonné quelques loisirs récréatifs afin de bronzer avec les radiations de votre moniteur.
Voici le premier épisode d'une petite série détente.

Retro-computing et MSX

Le retro computing ?

Ne me dites pas que vous n'avez jamais entendu parler du retro-computing!
- Il s'agit de la madeleine de Proust pour les gens qui ont passé leur belle jeunesse sur des micro-ordinateurs tels que MSX, Commodore, Atari, Amstrad...

Il y a des tas de moyen de s'amuser avec ces vieilleries, notamment par le biais des émulateurs.

Ces micros font certe pâle figure de nos jours, mais ils sont relativement faciles à programmer, grâce à la doc abondante que l'on trouve sur internet.
- Ils peuvent donc faire office de récréation mentale bien plus stimulante qu'un bête sudoku, entre deux développements fatigants.
- On peut également pratiquer cette discipline simplement pour s'amuser. Mais faire les choses pour s'amuser est assez mal vu de nos jours. Je vous laisserai donc le choix de chercher d'autres justifications rationnelles.

Le MSX

Pourquoi le MSX ?

Pourquoi programmer un MSX plutôt qu'un micro 32 bits de l'époque ?
- Tout simplement parce que le MSX est relativement simple avec son Z80 (8 bits). Avec un peu d'expérience de la programmation et des architectures, vous pouvez espérer avoir des résultats intéressants en moins d'une semaine. Si vos vacances sont plus longues, vous vous amuserez donc encore plus.
- Les micros 32 bits (68000 par exemple) sont plus puissants, mais nécessitent plus de connaissances et sortent un peu du cadre fixé par ce billet (s'amuser avec des choses simples).
- D'autre part, le challenge est très présent. Avec un Z80 à 3,58Mhz, chaque cycle compte!

Très bref historique du MSX

Je vais vous présenter succintement le MSX.
- Vous trouverez tout un tas d'articles sur le net, ainsi que des forums spécialisés, y compris en français.

En deux mots, le MSX a été une tentative de standardisation de la micro-informatique par les japonais (société Ascii Corporation), associés pour l'occasion avec Microsoft (pour le basic).
La norme MSX fut déclinée en plusieurs vagues:
- le MSX (appellé plus tard MSX 1)
- le MSX 2.
- En France, ça s'arrête là avec l'abandon de la commercialisation des modèles. Mais il y eu encore le MSX 2+, puis le MSX TurboR.
Tous les MSX furent basés sur un socle technique commun (pour la standardisation).
Ils furent vendus par d'innombrables marques (Sanyo, Philips, Sony, Canon, pour ne citer que les plus connues). Le microprocesseur était un Z80 pour toute la gamme. Seuls les MSX Turbo-R embarquaient un Z80 et un R800 (le R800 était un Z80 amélioré 16 bits, fonctionnant à 7 Mhz).
Au sein de la norme, il y eu quelques évolutions, notamment musicales: certaines cartouches de jeux étaient proposées avec un circuit sonore monté sur la cartouche (le SCC). Le SCC étendait les capacités sonores du MSX à 8 voies. D'autres extensions proposaient de la synthèse FM à un prix plutot concurrentiel pour l'époque (cartouche FM PAC).

Le MSX a péri face aux Amiga et autres Atari ST, supérieurs techniquement.
De cette période faste, il nous reste de beaux souvenirs, et la possibilité de retrouver les programmes de l'époque grâce aux émulateurs.
Il reste également quelques juteuses franchises, telles que Metal Gear ou Castlevania, qui ont débuté sur MSX.

Au fait, que signifie MSX ?

Microsoft SuXx ?

Pour en savoir plus

Topo Wikipedia court et clair
Wiki traduit à la hache du japonais, mais c'est une mine: Data Lullar

Mise en place des outils de développement

La base

Nous allons utiliser les outils modernes mis à notre disposition, avec Linux en tant qu' OS hôte.

Les principes et scripts sont transposables assez facilement à MS-Windows.
- Pour ce dernier, je vous conseille d'installer au plus vite un environnement Posix.
- Vous avez le choix entre Cygwin et MSYS/Mingw (j'ai une petite préférence pour ce dernier couple).
- Je signalerai par une note les adaptations à faire sous MS-Windows.

Choix de l'émulateur

Sous Unix, le choix est rapide: hors OpenMSX, point de salut.
- http://openmsx.sourceforge.net
Sous MS-Windows, vous pouvez utiliser MSX Blue qui a très bonne réputation (mais n'est pas multiplateformes).

Je supposerai que OpenMSX est correctement installé, et qu'il tourne avec un vrai bios MSX.
- En effet, par défaut il tourne avec C-Bios, qui émule les fonctions Bios, mais ne donne pas accès au basic.
- Ceci étant génant (le basic nous servira toujours un peu), mieux vaut un vrai bios d'origine.

La doc est ici: http://openmsx.sourceforge.net/docs.ph

Choix de l'éditeur texte

Vim. Des questions ?
- En fait, vous pouvez utiliser ce que vous voulez, même Emacs.
- Il faut juste que l'éditeur soit capable de traiter les fichier avec le format de ligne msdos (0xd 0xa).
- Vim et Emacs ont été porté sur les plateformes les plus exotiques. C'est donc un investissement dont vous toucherez les intêrets pendant de longues années.

Et le cross-assembler ?

Le principe est d'utiliser un cross-compilateur sur votre système hôte, et de fournir les fichiers compilés à l'émulateur.
Ceci permet d'automatiser au maximum toutes les manipulations :
- Le cycle édition / compilation / test / debuggage doit se faire naturellement, et ne pas être soumis à des manipulations continuelles.

Nous allons commencer par choisir un cross-assembler, l'automatisation du cycle de production sera abordée par la suite.

L'utilisateur MS-Windows utilise généralement tniASM.
- Tout le monde aime ce cross-assembler, et son mainteneur est encore vivant et présent sur IRC.
- Malheureusement, ce n'est pas porté sous Linux.
- On le trouve ici http://tniasm.tni.nl

Par contre , pour Linux... aie aie aie!
- Je ne pensais pas avoir autant de mal avec les cross-assemblers Z80 sous Linux.
- Sans plus attendre, passons au gros morceau.

Choix du cross-assembler Z80 pour Linux

Voici les résultat de plusieurs jours d'expérimentations.
- J'ai volontairement omis les cross-assemblers qui me paraissaient vraiment morts (ex: ZASM).
- Si j'en ai oublié des moins morts, merci de le signaler.

ASmsx

Je commence par celui dont je n'ai pas trouvé le site officiel.
Les sources ne semblent pas disponibles, du moins dans les archives que j'ai récupéré.
Il semble même ne pas y avoir de version autre que MS-Windows.
Il permet de réaliser facilement des ROMs avec les différents mappers MSX.

Pasmo

Pasmo semble déconseillé.
Il comporte quelques bizarreries, notamment la nécessité de commencer le code par la directive org. Ce qui donne org $C000-7 pour sauter le stub qui vient ensuite.
Mais certains projets l'utilisent, comme le C-BIOS.
- J'ai discuté avec quelques personnes gravitant autour du projet C-BIOS, ça n'a pas l'air d'être le fol enthousiasme. Plutôt un choix par défaut.

Je n'ai donc pas évalué Pasmo, certain de trouver mieux ailleurs.
- La suite de mes recherches me laisse à penser que je l'ai peut être éliminé un peu vite.

Sjasm

Grandeur et décadence de Sjasm

Sjasm semble jouir d'un crédit assez étonnant dans la communauté msx.
En fait, les anciennes versions étaient fonctionnelles, mais les plus récentes sont une vraie catastrophe.
Je vais développer, pour ne pas être accusé de taper sans raison sur un bon produit, ou de ne rien comprendre à la programmation.
Sjasm peut s'utiliser à partir d'un binaire (qui semble fonctionner), ou a partir des sources.
Je préfère compiler quand les sources sont disponibles, cela donne souvent de meilleurs résultats.
- Il s'agit ici de la version 0.42b8

Compilation de Sjasm 0.42b8

make donne des erreurs (je passe charitablement sur les warnings), notamment:
- datastructures.h:50: erreur: ‘memcpy’ was not declared in this scope
- (erreur répétée plusieurs fois dans ce même entête)

Explication: memcpy est considéré comme une fonction membre de Data.
- Data(byte *n_data,int n_size) : _data(0), _size(n_size), _maxsize(n_size) { _resize(n_size); memcpy(_data,n_data,n_size); }
- Ce n'est bien sûr pas le cas. Habituellement, memcpy est déclaré dans string.h.
- Faut-il faire un include de ce fichier au début de l'entête fautif ?
- memcpy n'est utilisé que dans datastructures.h, ainsi qu'un appel dans datastructures.cpp.
- voici son prototype: void *memcpy (void *dest, const void *src, size_t n);
- la véritable fonction memcpy renvoie un pointeur sur *dest

J'ai ajouté memcpy dans la classe Data (au début avant même le constructeur, dans les membres public bien sûr) :
- void *memcpy (byte *dest, byte *src, size_t n);
- et je l'ai défini ainsi dans datastructures.cpp:


void * Data::memcpy (byte *dest, byte *src, size_t n)
{
  for (int i=0; i<n; i++) dest[i]=src[i];
  return dest;
}

Toujours dans datastructures.c, on a ensuite une référence inconnue à memset (également déclaré dans string.h)
- void *memset (void *s, int c, size_t n);
- comprendre: rempli *s 'n' fois avec c
* C'était la seule référence. J'ai remplacé par une simple boucle.


//memset(_data+_size,0,nsize-_size);
 for (int i=0; i<nsize-_size; i++) _data[_size+i]=0;

Erreur suivante:
- errors.cpp:58: erreur: ‘exit’ was not declared in this scope
- toujours un include à ajouter:
- #include <cstdlib> (et non pas stdlib.h) dans errors.cpp (après le include "sjasm.h")

Et maintenant, il manque stdio
- fileio.cpp:37: erreur: ‘fopen’ was not declared in this scope
- (puis ensuite fclose, fseek, ftell, fwrite. En gros, tout la bande des I/O de stdio.h). On se demande à quoi sert de faire du C++ si c'est pour reprendre toute la librairie standard du C.
- On inclut #include <cstdio> (et non pas stdio.h) juste après le include sjasm.h au début de fileio.cpp.

Erreur suivante: valeur absolue
- rawsource.cpp:449: erreur: ‘abs’ was not declared in this scope
- prototype dans stdlib.h : int abs (int j);
- Ca calcule une valeur absolue. Bon, on va le faire nous même.


  int absolute=_offset%al;
  if (absolute<0) absolute=-absolute;
  if (_offset%al) _offset+=al-absolute; //abs(_offset%al);

Celui là, il est joli: reader.cpp:73: erreur: ‘malloc’ was not declared in this scope
- effectivement, il y a bien un malloc t: if (b.length()+1>64) bp=p=(char*)malloc(b.length()+1);
- Bon un free doit trainer quelque part, au milieu des delete.
- Vérifions tout de suite (grep free *). Ah tiens... non. memory leak en perspective ?
- #include <cstdlib> , après le #include "sjasm.h" (la routine quoi)

Allez , c'est le dernier:


sjasm.cpp:134: erreur: ‘exit’ was not declared in this scope
sjasm.cpp:145: erreur: ‘exit’ was not declared in this scope

Allez, include cstdlib again.

Et voila. L'exécutable sjasm est construit.

Il compile bien au moins ? Petit test...

Ca a l'air de fonctionner.

Patch pour Sjasm 0.42b8

J'ai donc écrit un patch que vous pourrez appliquer directement sur les sources du 0.42b8 si le coeur vous en dit.

diff -urNb sjasmsrc42b8 sjasmsrc42b8.jseb >sjasm42b8.patch
- Le résultat est un peu long pour être publié ici, je l'ai inclus sous forme de fichier.

Pour appliquer le patch:
- Placez-vous dans le répertoire des sources de Sjasm, et copiez-y le patch
- Lancez la commande patch : patch -p1 < sjasm42b8.patch

Une fois les fichiers patchés, vous pouvez lancer make (ne faites pas attention aux warnings, je n'ai pas corrigé cette partie).

Sjasmplus

Voyons voir Sjasmplus, qui est un fork d'une ancienne version de Sjasm.
Houlala, sur le site officiel, il y a un lien pour les recommended text editors.
- Ok, ni Vim, ni Emacs, ni même Ultraedit. Ca commence bien. Je n'ai même pas envie de reprendre les sources pour tout dire.

Allez, courage.
- Bon alors, il y a une stable, et une version de dev. La version de dev n'inclue pas le scripting avec Lua.
- Je reprends la stable, on verra la version de dev plus tard, éventuellement.

La version stable est la 1.06 (3 aout 2006)

Je lance la compilation.
- A première vue, autant de warnings que chez son petit frère Sjasm.
- Ah, et voici les premières erreurs:


Sjasm.cpp:167: erreur: ‘MAXPATHLEN’ was not declared in this scope
Sjasm.cpp:199: erreur: ‘zoekpad’ was not declared in this scope

Là j'avoue, je n'ai pas trop cherché.
- car c'est alors que je suis tombé sur ça:


#ifdef WIN32
int main(int argc, char *argv[]) {
#else
int main(int argc, char **argv) {

Il se faisait tard, j'ai laissé tomber.

Je me demande à quoi pensait le type qui a écrit ça.

z80-asm

z80-asm, avec un tiret dans le titre
- Je précise pour le tiret, car il a un homonyme sans tiret (qui est le prochain abordé).

z80-asm semble complet : il inclut même un moniteur/debugger interactif à l'ancienne (dans un terminal avec interface façon ncurses).
- http://wwwhomes.uni-bielefeld.de/achim/z80-asm.html

Le problème est sa rigidité syntaxique.
- Il ne veut pas des instructions db de mon programme de test.
- Il faut remplacer les db par des defb, les dw par des defw, etc...
- Les strings ne sont admises qu'avec une déclaration defm (defb ne passera pas).

Pour illustrer ce problème, cette déclaration sera refusée:


LABEL: defb "Hello",13,10,0

Et il faudra l'écrire comme ceci:


LABEL: defm 'Hello chput'
       defb 13,10,0

Attention, pour avoir l'aide, c'est -h. Et non pas --help ou -help.
Si vous ne précisez pas de fichier de sortie, la syntaxe du programme sera vérifiée, mais vous aurez le message: No code generated même si vous n'avez pas d'erreur.

Par défaut, z80-asm rajoute un header qui empêche toute exécution par le msx, et il prend au pied de la lettre la directive org $c000 en générant un binaire de 48 Ko!


jseb ~/msx $ hexdump -C test-z80-asm.bin
00000000  5a 38 30 41 53 4d 1a 0a  00 00 fe 00 c0 1b c0 00  |Z80ASM..........|
00000010  c0 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0000c000  00 00 00 00 00 00 00 00  00 00 21 0d c0 7e 23 a7  |..........!..~#.|
0000c010  c8 cd a2 00 18 f7 c9 48  65 6c 6c 6f 20 63 68 70  |.......Hello chp|
0000c020  75 74 0d 0a 00                                    |ut...|
0000c025

Pour les informations sur le header, voir dans la doc: z80-file.5 (ou man z80-file si vous avez installé les pages man).
- En gros, il faut enlever les 10 premiers octets.

Pour comparaison, le même programme généré avec Sjasm.


jseb ~/msx $ hexdump -C sjasm.bin
00000000  fe 00 c0 1b c0 00 c0 21  0d c0 7e 23 a7 c8 cd a2  |.......!..~#....|
00000010  00 18 f7 c9 48 65 6c 6c  6f 20 63 68 70 75 74 0d  |....Hello chput.|
00000020  0a 00                                             |..|
00000022

Je n'ai pas trouvé la façon d'enlever l'entête dans le manuel de z80asm.
- Du coup, je l'ai fait moi même avec un coup de dd.
- dd if=test2.bin of=raw.bin ibs=1 skip=10
- Mais ne vous fatiguez même pas à essayer. Le code ne s'exécutera bien sûr pas dans l'émulateur.

Dommage, cet assembleur semblait un bon candidat, abstraction faite de sa syntaxe rigide.
- Le package possède également un moniteur, déja évoqué ci-dessus.
- Cela dit, rien ne vous empêche d'utiliser le moniteur et de compiler avec un autre cross-assembler.

z80asm

Un bon petit cross-assembler, un peu limité mais à l'approche facile.
Le nom ressemble fortement au précédent, et se différencie par l'absence de tiret (ça devient subtil).
- Mais cette fois, nous avons affaire à un produit plus utilisable

Il a été développé par un possesseur de msx: Bas Wijnen (son pseudo est Sheveks)
- http://savannah.nongnu.org/projects/z80asm

Bonne surprise, le code source compile sans erreurs ni warnings.

Certaines fonctionnalités sont absentes:
- Exemple tiré du manuel: rlc r,(ix+nn) and friends don't work
- Cela ne me parait pas bien grave, et il y a toujours possibilité de faire une macro pour assembler directement l'instruction en écrivant les octets des instructions avec une séquence db.

Côté directives, c'est le minimum syndical: defb/db, defwdw, ds/defs , include, if/else/endif.
- Pas de macros ni de incbin pour ajouter directement des fichiers binaires.
- Pour incbin, ce n'est pas bien grave. On peut transformer des données binaires en db/dw, et les inclure avec la directive include.

La doc est ici: http://www.nongnu.org/z80asm/

Mon programme de test a été assemblé sans problèmes, sans adaptations syntaxiques, et a parfaitement fonctionné sous OpenMSX.
Bien que limité, z80asm semble être un bon choix pour le programmeur pressé de faire ses premiers programmes.

WLA DX : le meilleur pour la fin

Des caractéristiques alléchantes

C'est un projet vivant avec des patches récents (aout 2010).
Ce cross-assembler supporte d'autres processeurs que le Z80 (6502, 6510 ...)
- Pour ne rien vous cacher, la désignation complète est Yet Another GB-Z80/Z80/6502/65C02/6510/65816/HUC6280/SPC-700 Multi Platform Cross Assembler Package.

A noter que la compilation et le link sont séparés, ce qui permet de linker des objets entre eux, ou des libs.
- Cette séparation des commandes parait aller de soi, mais elle est absente des cross-assemblers que j'ai testé jusqu'à présent.
- Pour plus de détails, référez-vous aux sections compiling et linking dans le README (section 9 et 10).

Les possibilités offertes par les directives disponibles sont impressionantes.
- Attention, il y a quelques pièges que je détaillerai plus loin.

La doc n'est pas toujours très claire, mais elle est complète.
- Il ne faudra pas hésiter à faire quelques allers-retours dans la doc. Les informations sont parfois un peu éparpillées.

Compilation de WLA DX

Compilateur et linkers étant séparés, il va falloir procéder en deux temps.

La dernière version sur le site de Ville Helin (son auteur) est la 9.5 (aout 2008).
- Les anciennes versions sont sur le site de l'auteur:
- http://www.villehelin.com/wla.html

Depuis, il est hébergé sur sourceforge.
- Le mieux est de récupérer les derniers commits avec subversion depuis le repository:
- svn co https://wladx.svn.sourceforge.net/svnroot/wladx wladx

Il faut ensuite aller dans le répertoire makefiles, et choisir celui qui nous intéresse.
- Dans notre cas, il s'agit bien sûr de makefile.unix.z80

Copier ce makefile dans le répertoire des sources du compilateur (répertoire racine \"wladx\").
- Modifiez le pour virer le flag -O3 et mettre un -O2 à la place.

make clean && make -f makefile.unix.z80
- Le make clean est là au cas où une autre architecture aurait été compilée auparavant.
- Ainsi, le define -DZ80 sera bien pris en compte.

Pas de warnings inquiétants à signaler (n'oublions pas que les flags sont assez durs: -ansi -pedantic -Wall ! )
- Lancez l'exécutable obtenu (wla-z80).
- La première ligne doit indiquer qu'il s'agit de la version Z80 :


/tmp/wladx$ ./wla-z80 

WLA Z80 Macro Assembler v9.5

Si vous obtenez la ligne ci-dessus, le compilateur est prêt.

Il reste à s'occuper du linker, qui lui est commun à tous les compilateurs supportés par WLA.
- Le linker se trouve dans le sous-répertoire wlalink

Il faut modifier wlalink/makefile.unix sur deux points:
- Remplacer -O3 par -O2 (comme pour le compilateur).
- Remplacer $(LD) par $(CC) (sinon la compilation plante lors du link sur la libc).

Vous pouvez maintenant faire un:
- make clean && make -f makefile.unix
- L'exécutable obtenu se nomme wlalink


/tmp/wladx/wlalink$ ./wlalink                                                  e

WLALINK GB-Z80/Z80/6502/65C02/6510/65816/HUC6280/SPC-700 WLA Macro Assembler Linker v5.7

Et voila, le linker est prêt également.

Test de WLA DX

WLA DX a une approche assez originale qui peut dérouter au premier abord.

Avant toutes choses, lecture (même rapide) obligatoire du README (91ko!) qui fait office de documentation principale.

Voici un programme de démonstration adapté à WLA DX, avec quelques explications.

; test.asm - for testing WLA cross compiler.
; jseb @ finiderire . com

.MEMORYMAP
SLOTSIZE $FFFF
DEFAULTSLOT 0
SLOT 0 $0
.ENDME

.ROMBANKMAP
BANKSTOTAL 1
BANKSIZE $FFFF
BANKS 1
.ENDRO

.section "BANKHEADER"
  .db $fe
  .dw start,end,start; 
.ends

.BANK 0 SLOT 0
.ORG $C000 

start:
     LD HL,label
aff: LD A,(HL)
     INC HL
     AND A
     RET Z
     CALL $A2 ; CHPUT
     JR aff
     RET

label: .DB "Hello, World",13,10,0
end: .equ $-1

Au début du programme, vous remarquez quelques directives:
- .MEMORYMAP et .ROMBANKMAP
- Elles servent à définir la structure des roms. Ici, j'ai fait au plus simple (un seul slot, une seule banque, la totalité de l'espace adressable par un Z80 assigné sur le même slot).

BANKHEADER est plus intéressant, et nécessaire pour écrire le stub de notre programme.
- les octets contenus dans BANKHEADER seront simplement ajoutés au début de l'objet, et ne provoqueront pas de décalage dans le calcul d'adressage à la compilation. Dans la doc, il est même précisé que c'est une option très utile pour le MSX (tu m'étonnes).

Le .BANK 0 SLOT 0 ne semble pas obligatoire, car notre cas est très simple. Mais dans d'autre cas, il peut être utile de spécifier la BANK ou le SLOT. J'ai donc laissé cette directive pour attirer votre attention sur son existence.

A propos de BANK et de SLOT, la terminologie employée ici n'ait aucun rapport avec le memory mapping du MSX , même si les mots sont identiques.

Avant de nous lancer dans la compilation et le link, un gris piège est à signaler:
- .equ est un alias pour .define
- c'est à dire: .define : Assigns a number or a string to a definition label.
- Dans l'exemple en dessous, on met donc start à zéro! Ce n'est pas le comportement habituel qui serait d'assigner la valeur de start à exec.
- exec: .equ start ;en réalité, met start à zéro !!
- Il semble qu'on ne puisse pas assigner de valeur à une étiquette en utilisant la valeur d'une autre étiquette. Par contre, on peut faire ça: exec: .equ $C000
- Ce qui n'a pas un grand interet (voire même peut être dangereux si on change la valeur de .ORG )

Pour la compilation :
- wla-z80 -o test.asm
- le flag -o sert à demander la génération d'un fichier objet.
- le nom du fichier objet est par défaut celui du fichier source avec l'extension .o

Pour le link :
- wlalink -b test.group test.bin
- le flag -b est important, car par défaut, c'est -r qui est utilisé. Et le flag -r sert à créer une rom.
- Le fichier test.group contient différents paramètres, dont le nom des fichiers objets à utiliser pour le link (voir la doc).
- Ici, le fichier test.group contient ceci:


[objects]
test.o

Il est réduit ici à sa plus simple expression.

Voilà un tour rapide de WLA. Vous en savez assez pour lire la doc et pouvoir m'expliquer comment générer une ROM avec ce compilateur!

Le cas des macro cross-assemblers

macro quoi ?

Un macro cross assembler est un cross compilateur classique, mais qui fonctionne avec un système de macros.
Les macros sont des regroupements d' instructions (ici, les mnémoniques), sous une seule instruction afin de faciliter la lecture.
Une macro sert à automatiser l'insertion d'un bloc d'instruction.
Le support par le compilateur des macros peut être plus ou moins étendu:
- Cela peut aller du simple remplacement de texte (comme une fonction inline) à l'intégration de la gestion des opérateurs arithmétiques et logiques.

Notez qu'il existe bien sûr des macro assemblers dédiés à la plateforme hôte. Ils ne sont donc pas cross-compilers.

Les macro-assemblers permettent d'introduire un peu de haut niveau dans le monde aride de l'assembleur.
- Le revers de la médaille peut être une génération de code bien foireuse, surtout pour des projets amateurs peu suivis.

Le macro cross-assembler AS

AS rentre dans le club très fermé décrit ci-dessus.
Son support des macros est suffisament étendu pour justifier un traitement à part.
Vous le trouverez ici:
- http://john.ccac.rwth-aachen.de:8000/as/

Voici un exemple de sa syntaxe


dbstr   macro   arg
        if      strlen(arg) > 1
         db     substr(arg, 0, strlen(arg) - 1)
        endif
        if      strlen(arg) > 0
         db     charfromstr(arg, strlen(arg) - 1) | 80h
        endif
        endm

Il m'a l'air ma foi fort intéressant...
- mais j'avoue que je commence à me lasser de tous ces tests.

Mes choix de cross-assemblers

Il faut bien choisir, alors voici mes préférés.

WLA DX, le meilleur et le plus exigeant

WLA DX est de loin le meilleur cross compiler que j'ai pu tester. Il y a un monde entre lui, et Sjasm par exemple.

Ses avantages:
- Le compilateur et le linker sont séparés, ce qui est une très bonne chose.
- Il compile sans warning inquiétants, ni erreurs, avec des flags qui ne pardonnent pourtant pas.
- La doc est bien fournie.
- Il est maintenu et réellement multi-plateformes, signe d'une bonne conception.
- Le code est en C, preuve de bon goût (mieux vaut écrire du C rustique et fonctionnel que du C++ qui compile à peine).
- Seule une relative complexité pourrait vous conduire à lui préférer z80asm (celui de Sheveks).

Ses inconvénients:
- Une façon de faire aux antipodes de la simplicité.
- Une doc pas toujours très claire.
- Nécessite surement un peu d'expérience en programmation pour être apprécié.

z80asm, rustique mais efficace

Celui-ci est simple, mais n'a posé de problèmes ni à la compilation, ni à l'utilisation.
D'autres part, il a été développé spécifiquement pour être utilisé avec un MSX.
- Cependant, contrairement à ASmsx, il ne permet pas de créer facilement des ROMs.
- Seuls quelques fichiers d'équivalences spécifiques aux MSX sont fournis.
Sa rusticité (peu de directives disponibles) ne doit pas faire oublier sa facilité d'emploi.

Sjasm 0.42b8, le pari

Avec Sjasm, vous avez un cross-assembler relativement séduisant sur le papier.
Ses sources font cependant assez peur, et le patch que je vous propose pour le compiler ne corrige que les erreurs bloquants la compilation.
Une fois que j'ai réussi à le compiler, mes programmes de tests sont passés sans problèmes.
A tester donc, pour les plus joueurs d'entre-vous.

Et pour les Windoziens, c'est tniASM

tniASM semble pas mal... pour MS-Windows.
- je continue à tanner son auteur sur IRC pour une version OpenSource.

Fini pour aujourd'hui

Le prochain sujet abordé sera l'échange de données avec l'émulateur, et l'édition facile d'un programme basic.
D'ici là, vous avez le temps de digérer ce billet un peu long.
- Vous pouvez même retourner sur la plage, le temps que j'écrive tout ça, les nuages sont partis.

Votre propre expérience des cross-assemblers m'intéresse! N'hésitez pas à poster vos remarques et ajouts.

Oukiléleclavier ? Oukellélasouris ? (ou: la bonne blague de Xorg)

Jean-Seb — Wed, 05 May 2010 18:47:00 +0200

Je me suis aperçu qu'il manquait un tag à mes billets.
Comment caractériser toutes ces nuisances qui gachent la vie de l'honnête administrateur système ?
J'inaugure dès à présent le tag pénible avec Xorg

Situation de départ

Le but était de faire 'une mise à jour de Xorg sous Gentoo.
- Pour ma part, il s'agissait de passer le serveur Xorg de la version 1.3 à la version 1.6.5.

Avis aux mécréants utilisateurs d'autres unixeries que Gentoo : continuez à lire, ceci concerne au moins également FreeBSD et Arch-Linux.

Echauffement

Installer Xorg implique souvent la mise à jour d'autres paquets.
Avant même le passage au paquet xorg-server, nous rencontrons une erreur.
La libpciaccess (en update) essaie d'installer un exécutable (scanpci) mais refuse de remplacer la version précédente.
- Cet exécutable provoque un conflit, car c'est un autre ebuild qui a construit la version précédente.
- On ne peut donc pas le supprimer sans réfléchir, car cela risquerait de casser l'autre ebuild.

Laissez tomber la méthode de résolution suggérée dans les messages, et faites plutôt:
- equery b scanpci : vous obtenez le nom du paquet qui contient l'ancienne version à remplacer.
- Il s'agissait du Xorg que vous tentez d'updater. Ma méthode (votre avis peut varier) : emerge -C xorg-server

Une fois ceci rêglé, vous pouvez relancer la mise à jour de xorg-server.

Plus de clavier, plus de souris

Pour le reste, la compilation, se passe plutôt bien.
Un emerge -va nvidia-drivers plus tard, Xorg démarre enfin.
Et là, plus de souris (huho) ni de clavier (haha).

Rendez moi mon clavier! (et ma souris aussi!)

Sortie de Xorg

Alors là, attention, c'est technique.
- Appuyez pendant 5 secondes sur le bouton marche/arrêt du PC.
- Si vous avez ACPI dans le noyau avec un script sur le bouton marche/arrêt, vous êtes sauvé et la solution déplorable de la ligne du dessus ne sera pas nécessaire.
- Les heureux utilisateurs d'un réseau local pourront également faire un ssh sur la machine coincée. Beaucoup plus propre, mais nécessite un cable réseau et un autre PC (et un daemon sshd sur la machine bloquée).

Divination avec les logs

Après le reboot, et en supposant que vous n'avez pas eu de problème de journalisation, vous vous retrouvez à nouveau devant la console.
- Si vous n'avez pas de chance, X est relancé aussi sec. Dans ce cas, il va falloir changer le niveau de démarrage de votre Linux.

Dans le log de Xorg, nous trouvons la source du problème (je ne vous montre que la partie concernant le clavier, la même chose est observable pour la souris):


$~  less /var/log/Xorg.0.log
(II) LoadModule: "kbd"
(II) Loading /usr/lib/xorg/modules/input//kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
        compiled for 1.3.0, module version = 1.1.0
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 0.7
(EE) module ABI major version (0) doesn't match the server's version (4)
(II) UnloadModule: "kbd"
(II) Unloading /usr/lib/xorg/modules/input//kbd_drv.so
(EE) Failed to load module "kbd" (module requirement mismatch, 0)

Parenthèse pour les paresseux

Si vous n'avez pas fait de mise à jour de Xorg depuis vraiment très longtemps, il se peut que vous ayez un autre problème.
En effet, dans la config de Xorg, les devices ont changé de nom à un moment donné.
Vérifiez donc que votre clavier et votre souris ont bien le driver convenable.


Section "InputDevice"

    Identifier  "Keyboard1"
    Driver      "kbd"

(snip)
    Identifier  "Mouse1"
    Driver      "mouse"

Je ne saurais en dire plus à ce sujet, car je n'ai que de vagues souvenirs de ce problème.
- De toutes façons, le problème a dû disparaitre de lui-même, depuis le temps. (l'optimisme est rare de nos jours, sachons le cultiver.)

Revenons à nos moutons

Il vous manque simplement deux mises à jour, oubliées par emerge.
emerge -va xf86-input-keyboard
emerge -va xf86-input-mouse

A noter que le problème se posera probablement également avec votre joystick, votre tablette graphique, et autres périphériques d'entrée.
- Un simple eix xf86-input vous en convaincra aisément.

Keyboard not found. Press F1 to continue.

J'ai profité de mon clavier retrouvé pour écrire ce billet.
Comme je ne vais pas non plus tout faire, je vous laisse écrire les commentaires.

MPD : le stream était presque parfait

Jean-Seb — Wed, 28 Apr 2010 00:11:00 +0200

Aujourd'hui, ce sont mes aventures pour streamer de la musique avec mpd.
Car mpd est beau, mpd est grand, mpd streame!
Merci à Frédéric Jolliton pour le coup de main lors de la mise au point. (et il a relu et clarifié, en plus)
MàJ 13 mai 2010 : gagner trois ko de bande passante avec shh
MàJ 31 jan 2013 : faire un paquet Arch pour une machine sans Xorg.

Résumé des épisodes précédents

Ce n'était pas forcément le plus intéressant, mais le premier billet est ici:
- MPD - musique par le daemon

Le streaming n'était pas le sujet de ce billet. Dans ma grande bonté, j'en refais donc un complet.

Comprenons-nous bien

Ce titre légèrement menaçant fait un peu vendeur de savonnettes dé-régulées cherchant à forcer l'entrée de votre habitation. Cette fois, il ne s'agit que d' une nécessaire introduction à ce qu'est réellement mpd.

De l'avantage du stream

Pourquoi écouter un stream , et ne pas décoder en local ?
- Vous ne compilerez qu'une fois le player.
- Vous ne dupliquez pas vos fichiers, vous n'avez pas besoin de les promener sur une clé usb ou un disque externe.
- Vous allez faire l'envie de vos voisins (en général, cet argument suffit à emporter la décision).

mpd n'est pas forcément ce que l'on croit

mpd est un player dont la sortie sonore se fait en local par défaut (c'est à dire, sur la machine où mpd est lancé).
- Les clients de mpd, tels que ncmpc ou gmpc (client Gnome) ne sont rien d'autre que des télécommandes pour mpd.
- Aucun d'entre eux ne permet d'écouter un stream.
- Ils ne savent qu'envoyer des commandes au daemon mpd.

Un client mpd est une télécommande ... donc cela signifie que seul le PC faisant tourner le serveur est en mesure de sortir du son, et que tous les clients associés à mpd ne servent qu'à contrôler celui-ci à distance ?
- Exactement ! Je n'aurais su mieux le dire !

mais mpd peut streamer

Néanmoins, si les clients spécifiques à mpd ne peuvent que le contrôler, mpd est capable de différents rendus.
- Les sorties locales, avec la configuration OSS , Alsa ou ... null (qui est bien un rendu local)
- Des sorties streamées, avec entre autres un serveur shoutcast, ou son serveur interne httpd.

Nous allons utiliser le serveur intégré à mpd, qui streame sans fioritures, tel une web-radio.

Dès à présent, il est utile de préciser que nous allons utiliser deux ports.
- Le port de commande de mpd, sur lequel nous pouvons connecter un client, ou lancer un telnet.
- Le port utilisé par mpd pour servir le stream. Celui-ci n'est actif que quand de la musique est jouée. Il est fermé dès que la musique est stoppée.

Préparation et configuration de mpd

Flags de compilation Gentoo


media-sound/mpd -alsa -ffmpeg mikmod musepack ogg vorbis lame

Votre avis concernant ffmpeg pourra varier, mais j'ai préféré limiter les temps de compilation sur une machine un peu limitée.
J'ai bien sûr retiré toute référence à Alsa (OSS étant inactif par défaut), vu que la machine hébergeant le serveur n'a même pas de carte son.

PKGBUILD pour Arch

Arch a déja son paquet, qui contient un tas de dépendances qui vont faire exploser votre serveur.

Le mieux est de reprendre le PKGBUILD de ABS, pour obtenir les flags de la distribution, et de l'adapter.

Penser ensuite à bloquer les mises à jour de MPD dans pacman.conf.

Voici les deux modifications que j'ai apporté au PKGBUILD :

depends

J'ai viré tout un tas de trucs qu'il ne fallait surtout pas installer, car invasif (trop de dépendances), ou inutile (jack), ou les deux (pulse, ahaha!). J'ai enlevé libmodplug après quelques hésitations, et je l'ai remplacé par mikmod.

Je me suis également permis d'ajouter le support Ogg-Vorbis.


depends=('libmikmod' 'libmad' 'libid3tag' 'libogg' 'libvorbis')

Il ne reste vraiment pas grand monde, mais ça devrait suffire.

options de ./configure

Le massacre continue avec les options de configure. Hâtons nous de virer cet horrible systemd, lastfm et autres soundcloud. Bon, ça ira plus vite si je vous donne le nouveau.


  ./configure \
    --prefix=/usr \
    --sysconfdir=/etc \
    --enable-httpd-output \
    --enable-id3 \
    --enable-mikmod \
    --disable-oss \
    --enable-vorbis

La reconstitution du PKGBUILD est laissé à titre d'exercice au lecteur, je me suis contenté ici de donner ce qui changeait, plutôt que de vous noyer sous les inutiles détails de ce qui ne changeait pas.

Création des répertoires nécessaires

mpd peut être lancé par un utilisateur lambda.
- Vous devriez mettre sa configuration dans le home de celui-ci, et ajuster le paramètre user dans le fichier de configuration.

Fichier de configuration

Voici mon fichier de configuration.

Je n'ai pas inclu tout ce qui ne sert pas, reportez vous au fichier /etc/mpd.conf pour plus de précisions.

Son nom et son emplacement dépend de l'utilisateur qui va lancer mpd.

root : /etc/mpd.conf

un utilisateur : /home/toto/.mpdconf

Pour vos essais, vous pouvez simplifier la situation en ne mettant pas de mot de passe, par exemple.


music_directory  "/home/toto/music"
playlist_directory  "/home/toto/mpd/playlists"
db_file  "/home/toto/mpd/database"
log_file  "/home/toto/mpd/mpd.log"
pid_file  "/home/toto/mpd/mpd.pid"
state_file  "/home/toto/mpd/state"

#ATTENTION : si vous ne lancez pas mpd en root, commentez «user»
#user  "toto"

bind_to_address  "0.0.0.0"
port  "1234"
password  "password@read,add,control,admin"
default_permissions  "" #pas de bras, pas de chocolat.

input {
        plugin "curl"
}

audio_output {
        type  "httpd"
       name  "My HTTP Stream"
        encoder  "lame"  # optional, vorbis or lame
        port  "5678"
        bitrate  "128"  # do not define if quality is defined
        format  "44100:16:1"
}
filesystem_charset "UTF-8"

bind_to_address : ne mettez surtout pas localhost ou 127.0.0.1 :
- Cela provoquerait un bind de mpd sur l'interface loopback. Toute connexion externe serait alors impossible.
- Cependant, vous pourrez toujours faire un tunnel ssh avec l'adresse "127.0.0.1"
- A la place de 0.0.0.0 on peut mettre l'IP d'une carte réseau. Par exemple pour une machine directement sur le net (avec une IP publique) on veut pas forcément rendre mpd accessible. Alors qu'en mettant l'IP de la machine sur le LAN (disons 192.168.1.1) ça ne sera accessible que sur le réseau local.

default_permissions : pour vos essais en connexion anonyme (sans mot de passe), vous pouvez mettre les permissions à fond avec read,add,control,admin.

Pour pouvoir vous connecter si vous avez compilé mpd avec tcp_wrapper (libwrap) , vous devrez peut-être ajouter dans /etc/hosts.allow


mpd: ALL

Premier lancement

Placez quelques fichiers musicaux dans le répertoire définit comme music_directory dans le fichier de configuration.

Le premier lancement se fera en local, avec l'utilisateur configuré dans mpd.conf

Au passage, nous allons créer la base de données.

Par la suite, la commande update sera envoyée par un client mpd.

Dans les anciennes versions, il suffisait de faire ceci:


toto@serveur ~$ mpd --create-db

Hélas, cette méthode ne fonctionne plus, que l'on soit simple utilisateur ou root. Ne croyez pas la FAQ qui prétend que l'on peut créer la base avec l'utilisateur root. Dans tous les cas, vous aurez cette erreur:


/tmp# mpd --create-db

** (mpd:32740): CRITICAL **: option parsing failed: Unknown option --create-db

Alors que faire ?

D'autres sources conseillent de faire un mpc update, mais encore faudrait-il que mpd soit lancé. Or, mpd se plante au démarrage puisque la base de données n'est pas là.

Résistez également à la tentation de faire un touch pour créer la base à la main. Ça ne fonctionnera pas.

La seule chose que j'ai trouvé a été de créer une config minimale dans /etc/mpd.conf et de lancer mpd en tant que root. Ensuite, je l'ai tué et j'ai récupéré le fichier database.db à l'endroit où mpd l'avait créé (j'avais tout mis dans /tmp).

Alors pour info, il s'agit d'un stupide fichier texte. Le voici, si vous rencontrez les mêmes problèmes, un copier/coller pourrait vous faire gagner du temps.

Le dump après le cat vous donne le format binaire strict, au cas où vous auriez des problèmes avec votre éditeur (rappel: sous Unix, une fin de ligne est codée sur un seul octet: 0x0a).


/etc# cat /tmp/database.db 
info_begin
format: 1
mpd_version: 0.17.3
fs_charset: UTF-8
tag: Artist
tag: ArtistSort
tag: Album
tag: AlbumArtist
tag: AlbumArtistSort
tag: Title
tag: Track
tag: Name
tag: Genre
tag: Date
tag: Composer
tag: Performer
tag: Disc
tag: MUSICBRAINZ_ARTISTID
tag: MUSICBRAINZ_ALBUMID
tag: MUSICBRAINZ_ALBUMARTISTID
tag: MUSICBRAINZ_TRACKID
info_end

/etc# hexdump /tmp/database.db  -C
00000000  69 6e 66 6f 5f 62 65 67  69 6e 0a 66 6f 72 6d 61  |info_begin.forma|
00000010  74 3a 20 31 0a 6d 70 64  5f 76 65 72 73 69 6f 6e  |t: 1.mpd_version|
00000020  3a 20 30 2e 31 37 2e 33  0a 66 73 5f 63 68 61 72  |: 0.17.3.fs_char|
00000030  73 65 74 3a 20 55 54 46  2d 38 0a 74 61 67 3a 20  |set: UTF-8.tag: |
00000040  41 72 74 69 73 74 0a 74  61 67 3a 20 41 72 74 69  |Artist.tag: Arti|
00000050  73 74 53 6f 72 74 0a 74  61 67 3a 20 41 6c 62 75  |stSort.tag: Albu|
00000060  6d 0a 74 61 67 3a 20 41  6c 62 75 6d 41 72 74 69  |m.tag: AlbumArti|
00000070  73 74 0a 74 61 67 3a 20  41 6c 62 75 6d 41 72 74  |st.tag: AlbumArt|
00000080  69 73 74 53 6f 72 74 0a  74 61 67 3a 20 54 69 74  |istSort.tag: Tit|
00000090  6c 65 0a 74 61 67 3a 20  54 72 61 63 6b 0a 74 61  |le.tag: Track.ta|
000000a0  67 3a 20 4e 61 6d 65 0a  74 61 67 3a 20 47 65 6e  |g: Name.tag: Gen|
000000b0  72 65 0a 74 61 67 3a 20  44 61 74 65 0a 74 61 67  |re.tag: Date.tag|
000000c0  3a 20 43 6f 6d 70 6f 73  65 72 0a 74 61 67 3a 20  |: Composer.tag: |
000000d0  50 65 72 66 6f 72 6d 65  72 0a 74 61 67 3a 20 44  |Performer.tag: D|
000000e0  69 73 63 0a 74 61 67 3a  20 4d 55 53 49 43 42 52  |isc.tag: MUSICBR|
000000f0  41 49 4e 5a 5f 41 52 54  49 53 54 49 44 0a 74 61  |AINZ_ARTISTID.ta|
00000100  67 3a 20 4d 55 53 49 43  42 52 41 49 4e 5a 5f 41  |g: MUSICBRAINZ_A|
00000110  4c 42 55 4d 49 44 0a 74  61 67 3a 20 4d 55 53 49  |LBUMID.tag: MUSI|
00000120  43 42 52 41 49 4e 5a 5f  41 4c 42 55 4d 41 52 54  |CBRAINZ_ALBUMART|
00000130  49 53 54 49 44 0a 74 61  67 3a 20 4d 55 53 49 43  |ISTID.tag: MUSIC|
00000140  42 52 41 49 4e 5a 5f 54  52 41 43 4b 49 44 0a 69  |BRAINZ_TRACKID.i|
00000150  6e 66 6f 5f 65 6e 64 0a                           |nfo_end.|
00000158

En cas d'erreur, ou de modification de la base, vous pouvez tuer le serveur avec :
- kill $(pidof mpd)

Par la suite, vous pourrez utiliser les scripts Gentoo (ou de votre distrib) pour demander le démarrage de mpd au boot.

Test rapide avec telnet

Plus qu'à tenter un telnet sur le port de votre serveur

Vous pouvez trouver toutes les commandes comprises par mpd ici:
- commandes mpd


toto@serveur ~/.ncmpc $ telnet localhost 1234
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OK MPD 0.15.0
status
volume: -1
repeat: 0
random: 0
single: 0
consume: 0
playlist: 3
playlistlength: 0
xfade: 0
state: stop
OK
close
Connection closed by foreign host.

status vous permettra d'obtenir rapidement confirmation du fonctionnement de mpd.
- Même si la simple réussite de la connexion telnet devrait suffire.

Pour fermer proprement la session, utilisez close.

mpc dépanne certes bien...

Maintenant que le daemon mpd fonctionne, il est temps de tester avec un logiciel un peu plus évolué, et à distance.
- Je vous conseille de rester sur le réseau local de mpd, ceci limitera les ports à ouvrir dans le firewall, et vous pourrez toujours vous passer d'authentification.

L'informatique aime les acronymes, et les doublons aussi.
- mpc = music player client
- ne confondez pas avec les vieux fichiers musepack (extension mpc) que l'on peut jouer avec mpd.

mpc est un utilitaire indispensable pour vous éviter des telnet rapidement saoulants sur le port du daemon mpd.

Je vous laisse faire man mpc , le fonctionnement est trivial.

...mais ncmpc est toujours le plus beau

Maintenant que tout semble bien tourner, il est temps de passer au client qui ne nous quittera plus.
Avec un nom à coucher dehors, ncmpc est néanmoins le plus agréable des clients mpd.
Interprétation personnelle du nom:
- nc = ncurses
- mpc = music player client

Version dans Portage (avril 2010)

0.14
- un peu vieille, mais que voulez-vous ...

Flags Gentoo


media-sound/ncmpc artist-screen colors help-screen key-screen lyrics-screen search-screen song-screen

Beaucoup de possibilités dans les versions récentes de ncmpc , y compris la possibilité d'afficher les paroles des chansons.
- J'ai activé toutes les options, ça ne mange pas de pain (ni de ressources).

Erreur possible à la compilation de ncmpc


match.c:43: attention : implicit declaration of function ‘g_regex_match_simple’
match.c:45: erreur: ‘G_REGEX_CASELESS’ undeclared (first use in this function)

Dans ce cas, il faut mettre à jour votre glib (pas la glibc , je parle bien de la glib tout court) et recommencer l'emerge de ncmpc.

Fichier de configuration de ncmpc

Il se trouve dans ~/ncmpc/config
Celui-ci est donné juste pour information. Je n'ai pas encore pris le temps de fignoler.


port = 1234
password = "password"
scroll = yes
scroll-sep = " ***** "
enable-colors = yes
color background = black
color list = brightwhite

Diagnostics

Lancez la lecture d'un fichier avec mpc, ncmpc, telnet, ou ce que vous voudrez.
- Ceci doit produire l'envoi du stream sur le port défini pour httpd dans la configuration de mpd.
- Le port stream ne sera ouvert que pendant la génération d'un stream.


toto@serveur ~$ netstat -pln | grep mpd
tcp        0      0 0.0.0.0:1234            0.0.0.0:*               LISTEN      3694/mpd
tcp        0      0 0.0.0.0:5678            0.0.0.0:*               LISTEN      3694/mpd

Les ports utilisés sont ceux définis dans mpd.conf
- Le port de commande de mpd est 1234.
- Le stream est joué sur 5678.

La config du pauvre, mais qui marche tellement bien

Et encore j'avais un titre plus long pour cette partie, mais il faut savoir rester raisonnable.

Nous allons utiliser un tunnel ssh dans lequel nous ferons passer le flux.
- Ceci nous évitera de partager nos disques avec la terre entière, ce qui serait non seulement illégal, mais très consommateur en bande passante.

Tunnel ssh

Ce n'est pas le sujet de ce billet, je vous donne donc la commande pour créer un tunnel ssh.
- Il y a pas mal d'explications à ce sujet un peu partout, les curieux devraient trouver leur compte facilement.
- Sous MS-Windows, vous pouvez créer facilement des tunnels avec Putty.

pour créer un tunnel ssh entre votre machine et le serveur mpd


ssh -C -L 5678:localhost:5678 a.b.c.d

5678 : port configuré sur mpd pour exporter le stream httpd (ce n'est pas le port de commande de mpd)
localhost : car vous allez vous connecter sur votre machine pour la redirection de port.
a.b.c.d : ip de la machine distante faisant tourner mpd.

En prime, vous récupérez un shell où vous pourrez lancer ncmpc pour controler mpd.

mpd

Exporte le flux httpd.
Les façons de le lancer ont été vues plus haut:
- en user : mpd
- au démarrage : voir la doc de votre distrib. Avec Gentoo, vous pourrez utiliser /etc/init.d/mpd start

ncmpc

à installer sur le serveur pour controler mpd
- on peut également l'installer sur le client (dans ce cas, pensez à définir un login/password et à ouvrir le port de commande mpd dans le firewall).

mplayer

Reçoit le stream et assure son rendu.
mplayer http://192.168.1.1:5678
- 192.168.1.1 est l'ip de la machine faisant tourner mpd.
- 5678 est le numéro de port utilisé pour envoyer le stream.

Inconvénients de la config du pauvre (mais qui marche tellement bien)

Je ne vous le cache pas, il y a quelques inconvénients.

Overhead du tunnel

Si vous êtes vraiment court côté débit, sachez qu'un flux à 128kbs (minimum pour une qualité acceptable) vous pompe 16ko/s de bande passante.
- Avec le tunneling, vous allez passer à environ 22ko/s de moyenne.
Je n'ai pas testé avec quelque chose de plus compliqué, à base de OpenVPN par exemple.
- Si quelqu'un l'a fait, qu'il n'hésite pas à partager son expérience.

Pour gagner un peu de bande passante sur la session SSH, vous pouvez passer l'option -N à la connexion.
- Cette option désactive le shell interactif et ne fait qu'établir le tunnel.
- Vous ne pourrez donc plus controler la playlist directement, mais pour un streaming tout simple, cela suffit. Vous gagnez environ trois Ko/s.

Latence

C'est inhérent au streaming. Pour assurer une liaison sans saccades, tout est bufferisé.
- Les modifications côté serveurs (changement de chanson, ou arrêt pur et simple) mettront quelques secondes avant d'être répercutées à votre client.

Quand à l'avance/retour rapide dans un morceau, mieux vaut oublier tout de suite.

Une idée pourrait être de réduire la taille du buffer , sur une liaison de bonne qualité bien entendu.

Allez, c'est pas si mal finalement

De toutes façons, vous n'auriez guère mieux avec un serveur shoutcast, alors pourquoi se compliquer la vie ?

Allez hop. Et profitez-en pour mettre Audacious à la poubelle avant de sortir.

La plomberie facile avec mtrace

Jean-Seb — Mon, 22 Feb 2010 21:37:00 +0100

Le C et les fuites mémoires, c'est comme une vieille complainte sentimentale.
Avec mtrace, et sa couche maxi-absorbante, finissez-en avec l'incontinence de vos programmes.
mtrace n'est pas disponible en pharmacie, uniquement dans les bonnes libc.

Ma mémoire prend la fuite!

Je ne vous fait pas une tartine sur les problèmes de gestion mémoire en C.
- Si vous avez approché un compilateur C un jour de votre vie, vous savez de quoi je parle.

Pour prévenir les problèmes de fuite mémoire, il existe plusieurs méthodes.

Je ne fais rien

Ne rigolez pas, un OS bien conçu est censé vous rendre la mémoire à la sortie de votre programme.
Bon alors, on fait comme ça ?
- Non, on ne fait pas comme ça. On passe toujours un coup de balai avant de quitter un programme, question de savoir-vivre et d'éducation.
- Il y a également le fait qu'on ne sait jamais vraiment où le programme finira par tourner, ni si l'OS réussira réellement à récuperer toute la mémoire.

J'écris mon gestionnaire mémoire

Allez, on l'a tous fait un jour ou l'autre.
- Ou comment finir avec un wrapper de malloc/free plus ou moins élaboré, qui génère de jolies listes d'alllocations/libérations.
Ce n'est pas forcément une mauvaise idée. C'est surtout délicat à gérer pour toutes sortes de raisons (je ne développe pas, si vous ne comprenez pas, essayez de faire le votre).
L'insensé tenant vraiment à explorer la Voie de l'Insomnie pourra toujours commencer par : man malloc_hook.

J'utilise mtrace

Et c'est la prise de conscience sur un titre judicieusement choisi.

mtrace, principe et utilisation

Prérequis

Une libc GNU.
Un compilateur GNU.

Principe

Le principe consiste à intercepter les appels à malloc et à free, et à tenir registre des allocations/libérations de mémoire.
Pour cela, vous initialiserez le wrapper de la libc avec mtrace() , et vous appellerez en sortie muntrace().

Utilisation

Il suffit d'inclure mcheck.h et vous pourrez utiliser les deux fonctions requises.
- mtrace : avant tout malloc().
- muntrace : après le dernier free().

Vous aurez également besoin d'une variable shell, pour indiquer où écrire le fichier de log.
- export MALLOC_TRACE = /path/to/log.txt

Une autre variable shell peut être utilisée: MALLOC_CHECK
- Normalement, son usage est d'indiquer le niveau de log.
- export MALLOC_CHECK = 2 : fait planter le programme si erreur malloc (je tenais à vous faire partager cette découverte).

Un script Perl (mtrace) pour mettre en forme le fichier de log.

L'exemple tant attendu

Source pour nos essais

/* mtrace.c */

#include <stdio.h>
#include <stdlib.h>
#include <mcheck.h>

int main(void)
{
  mtrace();

  char *freed = malloc(1024);
  char *leaked = malloc(1024);

  if (freed) free(freed);

  muntrace();
  return 0;
}

Pour compiler ce source, rien de spécial.
- gcc -g -Wall mtrace.c -o mtrace
- N'oubliez pas -g pour avoir les symboles dans la sortie de mtrace.

Et pour le lancer:
- MALLOC_TRACE=/tmp/mtrace.log ./mtrace
- Le prompt revient, pas de plantages, donc, pas de problèmes.
- Vraiment ?

Utilisation du script Perl mtrace

Tout d'abord, voyons à quoi ressemble le fichier log.


~test$ cat /tmp/mtrace.log 
= Start
@ ./mtrace:[0x40060f] + 0x1ea7460 0x400
@ ./mtrace:[0x40061d] + 0x1ea7870 0x400
@ ./mtrace:[0x400631] - 0x1ea7460
= End

De ce qui précède, on peut deviner aisément que le bloc mémoire situé à 0x1ea7870 n'a pas été libéré.
- Nous allons cependant rendre plus parlant ce fichier.

Le script mtrace s'invoque avec en paramètres l'exécutable à analyser (pour ses symboles), et le fichier log.


~test$ MALLOC_TRACE="/tmp/mtrace.log" mtrace ./mtrace /tmp/mtrace.log 

Memory not freed:
-----------------
           Address     Size     Caller
0x0000000001cb6870    0x400  at /home/jseb/test/mtrace.c:12

Voila qui est plus parlant.
- La ligne indiquée correspond au malloc() sans free() correspondant.

mtrace n'est cependant pas Dieu le Père Tout Puissant

mtrace ne vous protégera bien sûr pas des écrasements mémoire durant l'exécution de votre programme.
De même, les problèmes de gestion mémoire ne seront pas détectés. Il peut cependant vous signaler des free multiples.
Sa facilité d'emploi devrait toutefois inciter tout codeur un tant soit peu consciencieux à l'utiliser.
Une alternative consiste à laisser tomber malloc et free, mais je laisse ça aux gens qui ont des problèmes de mémoire.

Vim est ton ami.

Réussir son IUP avec Arch

IUP, qu'on ne présente plus.

De quoi avons-nous besoin ?

IM

ftgl

CD

IUP

Mauvaise méthode : s'acharner sur son PKGBUILD.

La méthode root et artisanale.

Les petits cochons seront bien gardés.

ftgl ? Une paille.

En avant avec IM.

Continuons avec CD.

Terminons avec IUP.

Le présent, c'est maintenant !

GUI moquait

Nvidia, Arch : un grand coup sur l'ABS

Nvidia et la sauvagerie

Les blobs sont sur la plage

Mais pourquoi de la sauvagerie ?

Haine vidia

Préparer un vrai paquet Nvidia

nvidia.install

PKGBUILD

makepkg

Installation

Module kernel.

La suite de façon classique

Un peu de nettoyage

IgnorePKG dans pacman.conf

Le calme est revenu sur l'ensemble de la distrib

Installation du diablotin

Où trouver des informations

L'indispensable

Le dispensable

Tester avec le live-cd (pour les méfiants)

Ramdisk pour /etc

Activer l'interface réseau

Installons d'abord (nous réfléchirons ensuite)

Insertion du CD

Partitionnement

À table

Particularités à connaître (ou: «fini Linux, fiston»)

Déplacement dans le buffer d'une console.

Ordre des paramètres.

Clavier en français sous la console

Particularités de tcsh

Connaître son système

Mise à jour du système

Troubeulchoutine

root et password

mot de passe root perdu

Alors, ils mangent des enfants chez #freebsd ?

SSD - nouveau disque, nouveaux problèmes

GPT et UEFI

Mais j'ai déjà installé Linux !

Snif, format et réinstalle ?

Identification du hardware

Sauver ce qui a déjà été installé à l'aide d'une clé usb

Partitionnement avec gptfdisk

Le GPT, qu'est-ce donc ?

Préparation des outils

Schéma de partitionnement et boot futur

Utilisation de gdisk

Support Kernel de GPT

Installation et configuration de GRUB2

Sauf que ça ne boote pas

Support du TRIM

Astuces diverses

L'option de montage noatime

Ramdisk pour /tmp

Compiler en ram

Il n'est quand même pas bien gros ce disque

L'espace s'étiole

Bon alors c'est le journal et les inodes ?

<balance>C'est root le coupable !</balance>

Fini de trimer

D'un Z qui veut dire Z80

Avertissement

Ramdisk pour `/etc`