Construire et installer un kernel complet c'est aujourd'hui tellement simple que ma nièce de 3 ans peut y arriver.. si je lui dicte 
. Moi ce que je cherchais depuis des lustres c'est comment ne construire qu'un seul pauvre petit module de rien du tout sans lancer pour cela toute la machine de guerre. L'astuce qui sauve d'une crise de nerf lorsque l'on cherche par exemple à hacker un pilote...
Trois cas de figure
Dans ce qui suit, nous allons trouver les étapes pour compiler trois types de modules :
- Un module propriétaire comme celui de nVidia.
- Un module de l'arborescence standard de Linux, typiquement après l'avoir joyeusement hacké.
- Un module hors de l'arborescence standard.
version des sources
La première chose à faire, dans les trois cas, est de récupérer les sources de la version courante de votre noyau. Je passe là dessus, tout le monde sait faire cela. Lorsqu'on est mandrivien, le seul piège est juste de ne pas se gaufrer dans le souk de numéro de version blindées d'acronymes changeant à chaque release et qu'aujourd'hui encore continue de m'intriguer. Exemple : linux-desktop-2.6.27-0.rc8.2mnb, c'est quelque chose tout de même...
Toujours dans le cas de la Mandriva, une fois les sources installés il ne faut pas oublier de modifier le fichier Makefile de sorte à ce que EXTRAVERSION corresponde bien à ce que vous renvoie uname -r. Si vous ne faites pas cela, vous allez avoir droit à un -1 Invalid module format à l'insertion du module ou une fin de non recevoir pour le pilote nVidia.
Copie de sauvegarde
Si notre but est de hacker un module existant, il vaut mieux sauvegarder une "ancienne version" de l'arborescence des sources.
cp -a /usr/src/linux-$(uname -r) /usr/src/linux-$(uname -r)-old
Configuration
Si vous n'avez pas de configuration à la racine des sources (.config), par exemple après le passage de M. Propre (voir plus loin), il faut en récupérer une de préférence compatible avec le kernel courant. C'est le rôle de la commande oldconfig qui va chercher cette configuration dans /boot/config.$(uname -r).
make oldconfig
Si votre but est d'installer le module nVidia ou un module hors de l'arborescence, vous pouvez passez cette étape, sinon il faut que vous vérifiez dans la configuration que votre module est 1/ bien activé 2/ compilé en tant que module indépendant (marqué [M]) et non pas comme module intégré au noyau (marqué [*]). Personnellement j'aime bien l'interface nCurse pour ce travail :
make menuconfig
Préparation
L'étape suivante n'est utile que pour les modules de type nVidia, elle consiste à préparer la compilation, générer un certain nombre de scripts, de fichiers de version, etc.
make prepare
Compilation du module
Pour ceux qui cherchent à compiler le module nVidia, ça s'arrête ici et il ne vous reste plus qu'à lancer sh NVIDIA-XXX.run.
Pour les autres, c'est là que l'astuce réside. Dans l'exemple suivant je cherche à créer le module fujitsu-laptop qui se trouve dans le dossier drivers/misc. Cela nous donne :
make drivers/misc/fujitsu-laptop.ko
Et oui... Tellement simple que c'est à pleurer en repensant au nombre de fois où je me suis frappé des compilations de kernel complètes sur des machines d'avant guerre... Et ce qui est encore meilleur, c'est que c'est exactement la même chose pour un module hors de l'arborescence :
make /usr/src/u810_tablet/u810_tablet.ko
Une fois que make à terminé son boulot, le module tout frais vous attend sagement dans son dossier, prêt à être inséré pour test :
modinfo drivers/misc/fujitsu-laptop.ko
insmod drivers/misc/fujitsu-laptop.ko
Installation
Pour installer le module, la commande make modules_install ne nous est ici d'aucun secours, il faut bidouiller cela à la main :
# on recopie le modules dans l'arborescence du noyau
cp drivers/misc/fujitsu-laptop.ko /lib/modules/$(uname -r)/drivers/misc/
# un coup de gzip pour qu'il ne choque pas au millieu de ses camarades :
gzip /lib/modules/$(uname -r)/drivers/misc/fujitsu-laptop.ko
# un coup de recalcul de dépendances si c'est un module qui n'existait pas avant (que vous n'avez pas écrasé en somme)
depmod
Voilà, maintenant nous pouvons tester le module "en vrai" :
modinfo fujitsu-laptop
modprobe fujitsu-laptop
Nettoyage et patch
Le ménage c'est utile si vous désirez transformer votre hack en un honorable patch. Mr Proper va en effet supprimer tout fichier que vous avez créé (objets, modules, scripts temporaires, configuration) mais pas ceux que vous avez modifiés. Attention cependant à sauvegarder votre configuration avant.
make mrproper
Et maintenant, un petit patch..
cd ..
diff -Naur linux-$(uname -r)-old linux-$(uname -r) > mon_super_hack-$(uname -r).patch
Conclusion
Voilà, c'est fini...
Dire qu'avant j'étais capable de faire un make menuconfig, configurer l'option que je voulais en module et lancer un make bzImage pour enfin avoir mon module.
Je considérais la perte de temps relativement faible car tout était déjà compilé sauf mon module mais la ton astuce je l'aime tout simplement et ca me paraît logique que les kernel-devs aient pensé a ça.
Merci en tous cas.
Oui bien sympa comme astuce ... je met au chaud.
C'est pas modprobe qu'on doit maintenant utiliser pour insérer un module?
instead, which is cleverer."
cf. man insmod:
"insmod is a trivial program to insert a module into the kernel: if the filename is a hyphen, the module is taken from standard input. Most users will want to use modprobe(
Ca n'a rien à voir mais y'a pas une balise pour empêcher drupal de me remplacer mon _(_8_)_ par une grosse boule à lunettes?
@jaguorondi "most user but not me"
modprobe fonctionne avec modules.dep (généré par depmod) tandis qu'insmod fonctionne avec un simple fichier .ko que tu aurais pu m'envoyer par mail. Les deux outils aboutissent au même résultat mais ne prennent pas le chemin, c'est un peu la différence entre rpm/urpmi.
PS: nan, y'a pas de moyen, faudrait que j'enlève ce filtre en fait
Hmmm... Autant d'habitude les articles présentés sont hyper complets, autant là, je reste un peu sur ma faim. Pour sûr, le mode opératoire est extrêmement court mais passe un peu vite sur certains points. Peut-être un avertissement "si vous n'avez jamais compilé le moindre noyau Linux auparavant, allez vous documenter un peu". Commentaires et questions...
- Le point sur la récupération des sources pourrait préciser a. soit d'aller chercher un .tar.bz2 directement sur kernel.org ou un de ses miroirs ou b. d'installer un package "kernel-source" adapté à la distribution courante.
- Le "make mrproper" n'est pas utile sur les sources d'un noyau qu'on vient de décompacter. C'est déjà clean, par définition. Il faut noter qu'il éradique tout ".config" présent.
- Le "make oldconfig" sous entend qu'on a un ".config" existant (généré par un "make config" (ou consorts semi-graphiques et graphiques)), non ? Ou alors le "make oldconfig" tenterait-il astucieusement de récupérer la config du noyau actuellement en train de tourner ? Ce serait fort... On me souffle dans mon oreillette qu'il prendrait, à défaut de .config existant, un modèle par défaut adapté à l'architecture courante... mais...
- On peut forcer la compilation d'un module donné même s'il n'est pas sélectionné comme étant à compiler dans la config du noyau ?
- Le tuto précise comment compiler un module et le charger... mais ce module, sous forme de .ko, reste dans l'arborescence des sources du noyau. Il n'est pas copié dans le dossier ou figurent les modules habituellement. Du coup, au prochain reboot, il faudra re-charger le module à la main. Peut-être un petit coup de "make modules_install" ?
Bref, tuto peut-être un chouia trop épuré.
J'ai l'air critique, comme ça, mais ça n'enlève rien à l'admiration que j'ai pour ce site et son auteur, redoutable pédagogue... et (semble-t-il) mandrivien, ce qui me fait me sentir moins seul au milieu de ces hordes d'Ubuntistes...
@AP Tu veux dire un peu plus dense comme cela ?
En fait j'étais en train d'unifier deux autres tutos avec celui-là. Là je partageais juste ma joie 
Ceci dit j'en ai profité pour intégrer toutes tes remarques !!
Juste un détail pour oldconfig, ton oreillette te souffle mal, elle parle en fait de defconfig. oldconfig va chercher dans les fichiers /boot/config.* celui qui va bien et le cas
échéant fait un defconfig.
"au milieu de ces hordes d'Ubuntistes"
)))
De quelles hordes parles-tu ? De celle qui aurait intitulé ce billet "comment compiler un module sous Ubuntu", ou de celle qui alerte sur le fait qu'"Il y aurait une faille de sécurité dans le noyau de l'Ubuntu !!!", ou alors celle qui annonce "la sortie éminente d'OpenOffice 4.236 pour Ubuntu" ?
<troll>Archlinux power :D</troll>
@Dup yep je l'aime bien aussi celui là. En fait j'aime bien toutes les distributions je comprends juste mal ceux qui en font une religion
@AP Tiens un truc qui devrait t'intéresser
cat /proc/config.gz | gunzip -
Raaah, moi aussi je pleure en pensant à tous ces noyaux recompilés pour rien. Merci c'est tellement simple en fait !
Sinon, j'ai mon UUOC detector qui viens de se déclencher
@JIL LOL je connaissais pas l'expression
En effet c'est plus compacte mais moi j'ai plus une philosophie "pipe it all", je ne sais jamais vers quoi j'envoie, je préfère donc mémoriser des briques :
ceci dit tu n'as pas tord à y réflechir 2 sec, ça doit ausi marche comme ça :
@ Ulhume : oui et mes balises < troll > ont été supprimé sans doute considéré comme balise invalide.
La distrib qu'elle est bien c'est la distrib ou on se sent bien
@Dup vala, je te les ai mises
Et une bonne distrib pour commencer Linux, c'est une distrib où au moins un très bon pote se sent bien
@Ulhume : Ah merci, car c'était une boutade de ma part et sans les balises ca fait mec sérieux
Super tuto mais je viens de le tester sur une mandriava 2009.1 avec un noyau 2.6.29 et j'ai l'erreur suivant lorsque je veux inserer un module nouvellement compilé :
no symbol version for struct_module
J'ai changé CONFIG_MODVERSIONS mais rien ni fait !
Quelqu'un à une idée ?
Merci de votre aide
Senufo
Là désolé je sêche, mais je vais pas tarder à migrer mon fujitsu et et vais donc être confronté au problème, je te dis cela dés que c'est fait.
La 2009.1 est sortie réellement ou c'est encore une RC ?
Poster un nouveau commentaire