La construction d'un noyau adapté à ses besoins passe par plusieurs étapes.
Création d'une nouvelle arborescence de sources que l'on pourra modifier à volonté en préservant les sources "originaux".
Configuration du noyau en choisissant le matériel et les fonctions utiles.
Dans l'arborescence usuelle du système GNU/Linux, le répertoire de
stockage des sources est : /usr/src. À partir d'une connexion
super-utilisateur (su ou login root),
voici la liste des commandes rituelles après le télechargement des sources du
noyau :
# cp linux-2.6.xx.tar.gz /usr/src# cd /usr/src # rm linux
# tar xvzf linux-2.6.xx.tar.gz # mv linux linux-2.6.xx # ln -s linux-2.6.xx linux
L'utilisation du lien symbolique (commande ln) permet de changer d'arborescence de sources. Il est préférable de conserver une arborescence «fonctionnelle» (en général celle de la distribution) à côté de l'arborescence de test.
Il existe 3 interfaces utilisateur possibles pour configurer un noyau : mode texte, mode texte avec menus et mode graphique.
Le mode texte est réservé aux configurations matérielles minimales et aux nostalgiques des consoles VT100. Il n'est pas très commode à utiliser.
# cd /usr/src/linux # make config
Le mode texte avec menu est très pratique pour les manipulations à distance via ssh par exemple.
Il est nécessaire que le paquet des bibliothèques de développement ncurses soit installé sur le système sur lequel on réalise la configuration. On s'assure de l'installation du paquet avec une commande du type : dpkg -l libncurses*-dev |grep ^ii.
# cd /usr/src/linux # make menuconfig
Le mode graphique n'est pas forcément le plus pratique. Il est nécessaire d'avoir une interface graphique en état de marche ainsi que le paquet des bibliothèques de développement de cette interface. Comme dans le cas précédent, on s'assure de l'installation du paquet avec une commande du type : dpkg -l libqt3*-dev |grep ^ii.
# cd /usr/src/linux # make xconfig
Une fois la commande make menuconfig lancée, on accède à la liste principale des options de configuration du noyau LINUX. On s'intéresse plus particulièrement à deux catégories :
Les fonctions réseau du noyau LINUX. Nous avons impérativement besoin de la pile de protocole TCP/IP et des outils nécessaires au routage entre plusieurs interfaces.
Les pilotes de périphériques. C'est dans cette catégorie que l'on accède à la configuration du sous-système RNIS/ISDN.
Il faut consulter le document Les fonctions réseau du noyau LINUX ([FIXME: ulink]) pour obtenir les informations nécessaires à l'utilisation des nombreuses options de configuration réseau.
Le chantier de refonte du sous-système RNIS dans la série 2.6 des
noyaux Linux n'étant pas achevé, nous allons utiliser le code des pilotes de
périphériques de la catégorie Old ISDN4Linux.
Comme indiqué précédemment, il est préférable d'utiliser le sous-système RNIS sous forme modulaire. Ce choix facilite l'identification des fonctions utilisées et la mise au point de la connexion. Un module peut être (chargé|déchargé) sans redémarrage machine.
L'utilisation de la transmission synchrone est déterminée ici. Ce choix impose l'utilisation du gestionnaire de connexion ipppd. Les trames HDLC du niveau liaison (voir Section 4.5.2, « Couche Liaison (2) ») sont traitées bit à bit. Ce mode de fonctionnement est beaucoup plus efficace que l'émulation des commandes AT (Hayes) d'un modem analogique.
On choisit d'utiliser la compression des en-têtes TCP avec l'algorithme de Van Jacobsen. Ce choix n'est pas bloquant même si l'équipement auquel on se connecte (Fournisseur d'Accès Internet par exemple) ne supporte pas cette compression.
Cette option autorise l'agrégation des canaux B pour atteindre un débit utile de 128Kbps. Voir Section 4.3.4, « L'allocation dynamique de bande passante ».
Cette option est hors du champ du guide. Les types d'interconnexion retenus ne prévoient pas une utilisation audio de la liaison RNIS.
On sélectionne ensuite la rubrique de la catégorie ISDN4Linux hardware drivers.
Avec une carte passive, l'établissement, le maintien et la libération des connexions téléphoniques sont gérés par le logiciel du sous-système RNIS. C'est pour cette raison que l'on doit choisir les paramètres du canal D ainsi que le type de carte.
Le jeu de composants Siemens baptisé HiSax constitue la référence historique de gestion des connexions RNIS. On le retrouve sur une quarantaine de modèles de cartes de différents constructeurs. Voir Section 5.1.2, « La liste des cartes supportées ».
Le standard de protocoles de signalisation sur le canal D Euro-ISDN est le plus répandu dans l'union Européenne. Voir Section 4.2, « Le développement des réseaux RNIS ».
Ces options sont soit inutiles dans une interconnexion de réseaux de données, soit inutilisables en Europe.
Choix du modèle de carte implanté dans la machine à configurer. Voir Section 5.1.2, « La liste des cartes supportées ».
Le modèle de carte utilisé pour réaliser les tests est identifié sous le nom Gazel.
Les cartes RNIS présentent une singularité relativement aux autres interfaces réseau. Si le jeu de composants HiSax est commun à une quarantaine de modèles d'interface RNIS, il n'en va pas de même pour la connexion au bus PCI. C'est à ce niveau que les difficultés de reconnaissance automatique de périphérique apparaîssent. Il sera presque toujours nécessaire de spécifier manuellement le type (ie. la marque) de carte utilisée.
Comme pour les cartes passives, il existe une liste de cartes actives supportées par le sous-système RNIS Linux. Voir Section 5.2, « Comment choisir un modem RNIS interne ? ».
Il existe un module pour le standard CAPI (Common Application Programming for ISDN).
Ces modèles d'interfaces RNIS ne sont pas étudiés dans ce guide.
Une fois la phase de configuration terminée, on passe à la compilation proprement dite. Voici une nouvelle liste de commandes rituelles :
# make ; make modules_install # cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.xx # cp System.map /boot/System.map-2.6.xx
Les caractères 'xx' correspondent à la version courante du noyau LINUX.
Vous êtes ici :