Retrouvez cet article dans : Linux Magazine 105

Que ne voila un titre prometteur, mais point de trépignements, ami lecteur, nous ne poserons ici que les fondements de l’édifice. Ce que je vous propose en toute humilité, c’est de vous familiariser avec le monde merveilleux des modules noyau. Au travers d’un exemple basique, nous apprendrons à écrire notre premier pilote et titillerons son device associé.

1. Utilisation basique

Avant de se lancer corps et âme dans l’écriture d’un module d’exemple, je vous propose de nous familiariser avec l’utilisation même des modules noyau. En effet, si ces derniers sont incontournables et très communément utilisés dans le monde GNU/Linux et FreeBSD, ils sont étrangement très peu populaires dans le Landerneau NetBSD. Non qu’ils ne soient pas supportés, loin de là, ou que leur programmation soit d’une complexité insurmontable, mais finalement très peu de parties du noyau trouvent leur version modulaire. Un simple petit tour dans le répertoire /usr/lkm suffit pour se convaincre du peu d’intérêt porté à la modularisation : Shocking, isn’t it ? Préalablement à toute manipulation, nous devons vérifier que notre noyau possède bien le support des modules chargeables. Évidemment, pour poursuivre notre périple, il sera indispensable de posséder les sources du système. Plutôt que de faire dans la finesse, je vous propose de télécharger l’intégralité de l’arbre des sources, ce qui vous permettra de vous plonger encore un peu plus dans l’étude du code source d’un OS du bien. En avant : Comme le laisse supposer la dernière commande, nous travaillerons sur la version 4.0 de NetBSD, dernière en date. L’article s’appliquera toutefois, à quelques modifications près (que nous mentionnerons), à n’importe quelle version de NetBSD supérieure ou égale à 2.0. Une fois l’arbre téléchargé, nous nous rendons dans le répertoire contenant les configurations et nous vérifions l’existence de l’option LKM où <architecture> correspond au type de CPU, par exemple i386. Si une telle ligne n’apparaissait pas, il serait indispensable à la bonne poursuite des opérations que vous l’ajoutiez à votre configuration, puis que vous recompiliez, puis installiez votre noyau NetBSD (http://www.netbsd.org/docs/guide/en/chap-kernel.html). À présent que nous savons que notre noyau supporte les LKM, nous allons voir quels sont les outils mis à disposition par notre système pour les manipuler. Un simple man lkm nous informe que ces utilitaires sont au nombre de trois :

• modload(8) pour charger un module ;
• modstat(8) fournit des informations sur les modules chargés ;
• modunload(8) pour décharger un module.

Pour illustrer l’utilisation de ces exécutables, prenons comme cobaye le module pf.o, le célèbre pare-feu issu des magiciens d’OpenBSD, candidat idéal, puisque désactivé par défaut, du noyau GENERIC, mais pourtant essentiel à la protection d’une machine : Parfait, tout semble fonctionner à merveille. Mais quid du chargement automatique d’un module lors de l’allumage de notre machine ? Tout est prévu. Pour activer ce chargement automatique, il est tout d’abord nécessaire de renseigner la valeur suivante dans le fichier /etc/rc.conf  1. Pour de plus amples informations sur l’utilisation des divers types de macros de gestion de listes chaînées (simples, doubles, circulaires…), reportez-vous à la page de manuel queue(3). Ces macros sont d’une puissance et d’une pratique telles que vous ne pourrez plus jamais vous en passer. ce qui aura pour effet d’interpréter le fichier /etc/lkm.conf dont voici un exemple qui signifie : 1) Charger le module /usr/lkm/pf.o. 2) - : sans option à passer à modload(8). 3) - : le symbole d’entrée sera de la forme xxxinit(). 4) - : aucun script de post-installation ne sera démarré. 5) - : aucune sortie de ld(1) ne sera loguée. 6) AFTERMOUNT : le chargement du module s’effectuera après le montage des systèmes de fichier. Je vous renvoie à la lecture du man lkm.conf pour l’intégralité des options possibles dans ce fichier. Désormais, à chaque démarrage de votre machine, le module pf.o sera chargé automatiquement après le montage des filesystems spécifiés dans /etc/fstab.

2. Bon, ça commence ?

Il va de soi que pour entrer dans le vif du sujet, vous aurez besoin, au minimum, d’avoir installé le set comp.tgz qui contient le nécessaire de compilation, ainsi que d’un éditeur de texte. Un dernier mot sur un aspect extrêmement important dans le monde BSD en général, et NetBSD en particulier. Avant de publier quoi que ce soit en direction d’une quelconque liste de diffusion ou autre système de soumission de code, je ne saurais que trop vous conseiller la lecture du fichier /usr/share/misc/style qui décrit la KNF ou " Kernel Normal Form ", véritable guide de bonnes manières sur l’art de la présentation d’un code source en société. Sur ces avertissements d’usage, nous pouvons commencer. Nous l’avons dit plus haut, chaque module chargé doit posséder un point d’entrée qui sera passé à ld(1) afin que ce dernier le lie au noyau. Le point d’entrée par défaut est xxxinit(), et si ce dernier n’est pas trouvé, c’est une fonction de la forme module_lkmentry() qui sera recherchée, où module est le nom du module dans le système de fichier. Par exemple, pour un module hello.o, le point d’entrée associé sera hello_lkmentry(). En pratique, le point d’entrée est constitué d’un simple appel à la macro DISPATCH, définie dans le header /usr/include/sys/lkm.h. Cette macro a la charge de répartir sur d’autres fonctions les actions de chargement, déchargement et récupération de statistiques. Nous retrouvons ici nos trois outils modload(8), modunload(8) et modstat(8). Mais voyons à quoi ressemble l’appel à notre point d’entrée : Évidemment, nous devons nous arrêter un instant sur cet amas tombé de nulle part. Jetons d’abord un coup d’œil aux arguments passés à cette fonction.

• lkm_table, comme son nom l’indique, n’est autre qu’une liste chaînée de type TAILQ1 contenant l’ensemble des modules chargés, ainsi que les informations relatives à ces modules. La structure est également visible dans le header /usr/include/sys/lkm.h.
• cmd, on peut s’en douter, est un entier décrivant une commande : LKM_E_LOAD, LKM_E_UNLOAD ou LKM_E_STAT.
• ver, quant à lui, permet de vérifier que le versionning de l’environnement de compilation du module correspond bien au noyau auquel il essaye de se lier.
• La macro DISPATCH distribue les appels, fonction de la commande invoquée, à :
• blah_lkmload() dans le cas d’une commande LKM_E_LOAD ;
• blah_lkmunload() dans le cas d’une commande LKM_E_UNLOAD ;
• blah_lkmstat() dans le cas d’une commande LKM_E_STAT.

Les arguments lkmtp, cmd et ver sont également publiés dans cette macro. Notez que la macro DISPATCH est un #define sur une autre macro, LKM_DISPATCH, qui à travers un switch(), distribue l’activité fonction de la commande LKM_E_* passée. Une dernière macro " générique " est nécessaire avant de démarrer l’écriture de nos gestionnaires de commandes : il s’agit de la déclaration du type de module. Cette déclaration est réalisée à l’aide des macros MOD_*. Ces macros peuvent être de type :

• MOD_SYSCALL, pour l’écriture d’un module implémentant un appel système ;
• MOD_VFS, si l’on souhaite implémenter un nouveau type de système de fichier virtuel ;
• MOD_DEV, probablement l’un des plus utilisés, vise l’écriture de drivers de type block ou character ;
• MOD_COMPAT, pour le support de systèmes d’exploitation étrangers ;
• MOD_EXEC, pour l’écriture d’un nouveau type de binaire ;
• MOD_MISC, " Miscellaneous modules ", pour faire à peu près ce que l’on veut, ce sera la macro de choix pour notre premier exemple.

Nous ajoutons donc au-dessus de la déclaration du point d’entrée : Pour réaliser une première version de notre LKM, nous allons utiliser la fonction lkm_nofunc(), toujours définie dans sys/lkm.h, et remplacer les handlers load, unload et stat par cette dernière. Vous l’aurez compris, la fonction lkm_nofunc() ne fait simplement rien. Voici le (petit) code de notre premier exemple : Reste bien sûr à écrire le Makefile associé, et, là encore, NetBSD va grandement nous simplifier la tâche. Grâce à l’important travail d’abstraction réalisé par les divers projets BSD, notre fichier Makefile se résume à : Explication dans le texte :

• L’include directory est évalué à partir d’une suite de commandes shell.
• Le nom du module généré sera blah.
• Le code source se résume dans l’immédiat au fichier lkminit_blah.c (ce formalisme est nécessaire au bon fonctionnement du framework de compilation des LKM).
• Nous ne génèrerons pas de manpage.
• Lorsque WARNS vaut la valeur 1, on passe à gcc les arguments -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional (voir /usr/share/mk/bsd.sys.mk pour la liste des valeurs possibles et leur implication).

Le cœur battant, nous lançons fièrement un make, à l’issue duquel, un fichier blah.o vient de faire son apparition dans le répertoire courant. Nous savons ce qu’il nous reste à faire : Victoire !

3. Un peu d’activité

Nous sommes donc en mesure de compiler, charger et décharger un module qui ne fait rien. Il est maintenant grand temps de créer des gestionnaires dignes de ce nom (ou presque) afin de mettre en place un véritable module qui " faitdestrucs ". Ce que nous nous proposons d’écrire est un bête LKM qui écrira quelque chose à son chargement, à son déchargement et à la réception de la commande stat. Il est de bon ton de vérifier l’existence d’un module afin de ne pas le charger plusieurs fois grâce à la fonction lkmexists(). Nous inclurons donc dans notre handler de chargement du module le code suivant : Voici à quoi ressemblent nos gestionnaires : Remplaçons maintenant les appels à lkm_nofunc() par de vrais appels aux fonctions de commande : Compilons, puis manipulons notre LKM : C’est quand même la sacrée classe ce printf() ! Le code de nos handlers n’étant pas spécialement conséquent, il serait du meilleur effet de les regrouper dans une seule fonction et de choisir l’action à mener à l’aide de switch() : Il suffit maintenant de retoucher l’appel à DISPATCH de cette façon : Beaucoup plus sexy.

4. Je-t’chatte, tu-t’chattes

Après cette petite mise en bouche, il est temps de s’attaquer aux choses sérieuses. Déblayons le terrain afin de préparer l’écriture de notre Nirvana, le Device Driver. Que souhaitons nous faire à l’aide de ce dernier ? Rien de bien méchant, voici le comportement visé : Cette interaction suppose que :

• Notre device doit pouvoir être lu.
• On doit pouvoir écrire dans notre device.

Pour publier ces fonctions de lecture/écriture, nous devons déclarer une structure de type cdevsw ou Character Device Switch, définie dans sys/conf.h, qui fait pointer les actions typiques d’un char device vers des fonctions adaptées. Intuitivement, nous imaginons qu’en plus des opérations de lecture/écriture, des fonctions d’ouverture et fermeture du device devront également être disponibles. Un rapide tour d’horizon du header sus-cité nous informe sur le contenu de la structure cdevsw : Plus bas dans le fichier, nous voyons comment annuler certaines opérations : Enfin, toujours dans sys/conf.h, on trouvera les valeurs applicables au champ d_type : Muni de ces informations, nous pouvons écrire la structure de données associée à notre futur device : La dernière étape de la préparation consiste à déclarer le type de module que nous allons écrire. Vous l’aurez certainement deviné, nous allons remplacer la macro MOD_MISC par MOD_DEV, dont voici les arguments expliqués :

• name : sous cette appellation incompréhensible, nous devrons indiquer le nom du module, blah dans notre cas.
• devname : ici nous indiquons le nom du device, nous souhaitons travailler sur /dev/blah, ce sera donc à nouveau blah.
• bdevp : il ne s’agit pas d’un block device, ce champ aura NULL pour valeur.
• bdevm : nous plaçons le major à -1, même si ce dernier ne sera pas utilisé.
• cdevp : ici, nous écrivons l’adresse vers la structure de donnée du device, &blah_dev.
• cdevm : nous souhaitons que le major du device soit attribué dynamiquement, nous inscrivons -1. Ce qui nous donne :
      MOD_DEV("blah", "blah", NULL, -1, &blah_dev, -1);

  1	MOD_DEV("blah", "blah", NULL, -1, &blah_dev, -1);

  Les pré-requis étant maintenant implémentés, nous pouvons passer à l’étape la plus intéressante de notre périple, l’écriture des fonctions associées au driver. Commençons par les plus triviales, blah_open() et blah_close(). Nous n’avons pour ainsi dire besoin de rien de particulier dans ces fonctions, mais pour la beauté du geste, rendons-les un peu verbeuses.

Comme on peut s’en douter, dev correspond au device courant, flag et mode, aux mêmes arguments utilisés par open(2), et l au lightweight process dans lequel nous nous trouvons. Le numéro de processus est retrouvé via le champ l_proc qui n’est autre qu’un pointeur sur le processus auquel est associé le thread. Attention Le prototype des fonctions open et close n’est pas backward compatible pour les versions antérieures à NetBSD 4.0. Il faudra remplacer struct lwp par struct proc, et p représentera alors le pointeur direct vers le processus appelant. Le code de fermeture du device est sensiblement identique : J’ai évidemment gardé le meilleur pour la fin, les fonctions blah_read() et blah_write(). Pour aborder ces fonctions, il faut noter que NetBSD met à notre disposition une structure, struct uio, permettant précisément de transporter des informations de l’espace noyau vers l’espace utilisateur et vice versa. De cette structure, nous utiliserons " consciemment " :

• explicitement, le champ uio_resid ;
• implicitement, le champ uio_rw ;
• implicitement, le champ iov_base de la sous-structure uio_iov.

La lecture du header sys/uio.h nous éclaire sur l’utilité de ces variables : Ainsi, nous comprenons que uio_resid représente la quantité de données en transit, uio_rw le mode d’accès à la structure, et uio_iov->iov_base l’adresse de base des données en transit. Ajoutons préalablement ces lignes en tête de notre code source : Pour faire circuler nos données d’un espace à l’autre, nous utiliserons la fonction uiomove(9). Nous pouvons alors écrire la fonction blah_read() de la façon suivante : Nous sommes ici dans une opération de lecture. Aussi, le champ uio_rw de la structure uio sera initialisé avec la valeur UIO_READ, ce qui aura pour conséquence d’indiquer à la fonction uiomove(9) d’effectuer un copyout(9), soit une copie de l’espace noyau vers l’espace utilisateur, donc de la variable inside vers le champ uio_iov->iov_base de la structure uio. Comme on peut le voir dans notre fonction, tant qu’il reste des données à transférer (uio_resid) et que le code d’erreur est nul, on continue de faire transiter des informations entre le noyau et l’espace utilisateur en s’assurant de transférer la plus petite quantité entre la taille maximale, MAXLEN, que nous avons spécifiée, et la taille restant à traiter dans la structure uio, uio_resid. Livrons-nous maintenant au même exercice pour la fonction blah_write : Avant d’écrire quoi que ce soit dans la variable interne, inside, nous mettons à 0 l’ensemble des octets de cette dernière, puis utilisons à nouveau la fonction uiomove(9), qui, puisque nous sommes dans une fonction d’écriture, placera son champ uio_rw à UIO_WRITE, indiquant ainsi que son rôle consiste maintenant à copier des données de l’espace utilisateur vers l’espace noyau. Le code complet de notre premier character device est le suivant : Et maintenant ? C’est l’heure du test final bien sûr ! Vous l’aurez noté, l’utilitaire modload(8) prend plusieurs arguments, et, parmi eux, un script d’initialisation quelconque. Comme vous vous en rappelez, le choix du major de notre character device est effectué dynamiquement. Aussi, il reviendra à modload de passer en argument à notre mini-script ce numéro de device. Le script s’articule ainsi : Il suffit alors d’invoquer modload(8) de la sorte : et de constater : Enfin, le moment de vérité : Et soudain, un sentiment de toute-puissance parcourt votre échine.

5. Ouuuh, j’me ferais bien un driver wifi moi

À travers ce minuscule exemple, c’est tout l’univers des mystérieux pilotes du noyau qui s’ouvre à vous. Bien des contrées restent à explorer, et bien des astuces manquent à l’appel, mais, d’ores et déjà, munis de ces quelques lignes, vous êtes en mesure de réaliser moult prouesses, des plus dignes aux plus obscures. Dans la lignée de cette introduction, je vous invite à vous pencher sur les différents types de macros MOD_*, mais, aussi et surtout, à parcourir l’arbre des sources du système NetBSD, source infinie d’inspiration. Notez, pour finir, que les exemples présents dans cet article s’adapteront sans peine au monde OpenBSD, le framework LKM ayant finalement peu évolué entre les deux OS. Liens

• FAQ sur la programmation noyau NetBSD : http://www.netbsd.org/fr/Documentation/kernel/programming.html
• Le guide de programmation de pilotes pour NetBSD : http://www.netbsd.org/docs/kernel/ddwg.html Lolcats : http://icanhascheezburger.com/

  Retrouvez cet article dans : Linux Magazine 105