Piti topo sur les modules


#1

Bonjour à tous.
Quelqu’un ayant exprimé sa méconnaissance du fonctionnement des modules, et comme ca ne correspondait plus trop au fil de discussion courant, je me permet de faire profiter un peu tout le monde de ma reponse.

[quote=“http://www.tldp.org/LDP/lkmpg/2.4/html/book1.htm”]
What exactly is a kernel module? Modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. For example, one type of module is the device driver, which allows the kernel to access hardware connected to the system. Without modules, we would have to build monolithic kernels and add new functionality directly into the kernel image. Besides having larger kernels, this has the disadvantage of requiring us to rebuild and reboot the kernel every time we want new functionality.[/quote]
Pour les non anglicistes: un module de noyau est un bout de code executable que l’on branche en cas de besoin sur le noyau pour lui ajouter une fonctionnalité. Ces fonctionnalités concernent le plus souvent la gestion d’un composant materiel, mais on trouve aussi des fonctionnalités de cryptage, ou d’optimisation, par exemple.

Pourquoi:
Historiquement, les modules ont été introduit pour éviter de construire d’enormes noyaux contenant d’enormes parties de code inutilisé le plus souvent. Par ailleurs, une autre contrainte à guidé l’allègement de ce noyau, c’etait de faire tenir l’ensemble des éléments minimaux pour démarrer dans une disquette 1.44 Mo: du coup, les modules nécessaires au boot - et seulement ceux la - sont regroupés dans un filesystem compressé (on appelle ca un initrd), qui est monté sur /initrd au moment du boot: c’est pour ca que le composant de decompression (cramfs sous debian) est un des seuls qui doive etre forcément integré au noyau, car il doit etre disponible AVANT les autres modules critiques, afin de pouvoir décompresser depuis le noyau l’initrd.
Au dela de ces conditions initiales, le détachement de ces bouts de code du noyau à permis de faire une économie de ressources mêmoire: seuls les modules effectivement utilisés par un peripherique restent chargés, les autres se déchargeant automatiquement quand ils ne trouvent aucun périphérique à gèrer. Par ailleurs, ces modules étant dans des pages mêmoire séparée peuvent donc être swappées, contrairement au noyau qui reste en permanence en mêmoire.
Finalement, la multiplication des périphèriques connectables à chaud, à donné une justification supplémentaire à cette logique “just in time”.

Ou:
la configuration (= le .config) qui a servi à compiler le noyau est dans /boot/config-
Les modules eux mêmes sont dans /lib/modules/

Comment:
Manipulation des modules:
liste : lsmod
insertion: modprobe
dechargement: rmmod

pour info, si noyau < 2.4 les modules sont des .o, aprés, ce sont des .ko, pour les différentier des .o traditionnels linkables…

le fichier /lib/modules//modules.dep, génèré par la commande “depmod -a”, contient la liste des modules, et de comment les uns dépendent des autres. On peut l’ajuster manuellement, pour y déclarer des modules qui ne sont pas dans l’arborescence /lib/modules//, mais attention, les modifs sont facilement écrasées par depmod.

Configuration:
pour tous noyaux, /etc/modules contient la liste des modules que l’on veut charger automatiquement au boot.

les modules acceptent parfois des arguments, que l’on peut connaitre avec 'modinfo :

  • pour les noyaux 2.4, on peut préciser ces éléments dans /etc/modutils. Le fichier modules.conf génèré automatiquement par ‘update-modules’ (du paquet modutils), contient la concatenation du contenu de ce dernier répertoire.
  • sous 2.6, /etc/modprobe.d et modprobe.conf, et le paquet module-init-tools jouent le même rôle respectif que les 3 précèdents.

bon, c’est tout pour aujourd’hui. Si vous avez des remarques, si j’ai dit une bitise, ou encore si vous avez des choses à rajouter, n’hesitez pas, je reviendrais affiner de toutes facon…
mais au fait, c’est vrai, il nous faudrait un wiki !!!


#2

En voilà une initiative qu’elle est bonne !
J’ai imprimé ce laïus et j’espère que je ne poserai pas un jour une question à laquelle il y est répondu.
Quoi que … :wink:


#3

Pas imprimé, mais bookmarké :wink:

J’ai décidé de prendre un peu de recul avec Linux, parce que je començais à perdre patience… Merci pour le topo ; j’y reviendrai de toute façon dans quelque temps (quand je serai calmé :stuck_out_tongue: )


#4

ou mieux : marque-pagé :laughing:


#5

c’est surtout à “bookmarquer”, parceque j’y reviendrais sans doute de tps en tps pour affiner…


#6

Pssst, rien de tout ça…
Je propose à notre valeureux scribe que sa prose, il la mette bien au chaud, dans la section “Documentation” du site debian-fr.org.
Comme ça on saura toujours oû la retrouver.
Seti pas bon ça comme idée :smiley:


#7

+1 jabba


#8

Bon alors, si j’ai tout bien compris:
quand je compile un nouveau module (ndiswrapper pour gérer mon wifi par ex), si je veux qu’ensuite ce module soit chargé systématiquement au démarrage, je rajoute dans /etc/modules la ligne ndiswrapper ?

Avec ces depmod, update-modules…je m’y perd .

En tout cas Bravo à MattOTop pour ce tuto qui m’a foi est indispensable pour les newbies :wink:


#9

oui, si le systême “hotplug” ne déclenche pas de lui même le chargement d’un module (ce qui est le cas le plus souvent) tu peux effectivement forcer son chargement au boot dans /etc/modules


#10

réactivation du fil


#11

Salut !
Je profite de ce fil pour quémander une aide à mon problème, qui est lié au déchargement autoamtqiue des modules :

Je bataille en ce moment pour configurer ma connexion wifi (dongle usb inventel sur livebox inventel) sur la Kaella 2.1. En utilisant ndiswrapper, j’y suis arrivé :

J’ai lancé ndiswrapper et chargé le inf du driver windows. (je l’ai fait 1 seule fois )
J’ai lancé #ndiswrapper -m pour créer l’alias ( idem 1 seule fois).

Puis j’ai placé “ndiswrapper” dans le fichier /etc/modules, pour qu’il démarre tout seul.

J’ai placé IP, passerelle, WEP, etc… dans /etc/network/interfaces

Tout fonctionne enfin avec firefox (au bout de 5h de recherche acharnée, heureusement que j’ai un autre pc sous la main qui a une connection internet fonctionnelle smile )

Je n’ai plus qu’un soucis :
Si je ne rentre pas la commande en root avant d’éteindre / de redémarrer la machine, l’arrêt se passe mal et bloque sur une multitude de lignes d’erreurs contenant “ndiswrapper” et “usb”.

Comment automatiser cette commande pendant l’arrêt du pc pour éviter les erreurs et le blocage?

Merci d’avance.

PS : si vous connaissais une manière plus propre d’initialiser la cnnection internet, je suis preneur :smiley: J’ai vu des exemples de scripts pour mandriva, mais je ne sais pas comment procéder sous debian.


#12

corwyn, je me suis permis de déplacer ta question ici:
forum.debian-fr.org/viewtopic.php?p=13544#13544


#13

Modules du noyau et options :

[quote=“R. Hertzog (depôt legal Mars 2005)”]
Les modules du noyau disposent eux aussi d’options qu’on peut paramétrer dans un fichier.
Les noyaux 2.4 utilisent pour cela /etc/modules.conf, généré par le programme update-modules à partir des informations du répertoire /etc/modutils/ .
Les noyaux 2.6 préfèrent /etc/modprobe.conf,incluant /lib/modules/modprobe.conf (généré par update-modules à partir des informations du répertoire /etc/modprobe.d/ ).
Ces changements sont liés aux évolutions du programme modprobe - Le programme permettant de charger un module noyau avec ses dépendances (les modules peuvent en effet faire appel à d’autres modules).

Pour un noyau 2.6, le programme modprobe correspondant provient ainsi du paquet modules-init-tools, et non plus de modutils.
Ces deux paquets coéxistent trés bien et les bons programmes sont employés automatiquement en fonction de la version du noyau.[/quote]


#14

MattOTop, pourrais-tu s’il te plait nous gratifier d’une brillante explication de :
How-To preparer la compilation d’un nouveau noyau reprenant les modules de l’ancien noyau que l’on aura ajoutés, et qui se trouve si je ne m’abuse dans :
/lib/modules/<version_noyau_dépassée>/repertoire_spécifique_du_module_ajouté/le_module ?

Si c’est possible, est-ce qu’il sera présent dans le menu config lors de la config du nouveau noyau ? sinon est-ce possible de l’y faire apparaître ?


#15

je ne comprends pas de quoi tu parles.
Tu as les modules compilés avec le noyau. Ca tu peux à peu prés en conserver la configuration de noyau en noyau, mais pour les modules “rajoutés”, même s’il ya des outils pour automatiser leur compilation avec chaque nouveau noyau, ca dépend de comment tu les a installés…


#16

Excuse moi mais c’est que c’est pas encore trés clair pour moi d’où ma question … je veux dire :

Oui en copiant le fichier /boot/config-2.6.x.x dans le repertoire du noyau à compiler …

Ensuite que faire pour que physiquement les modules rajoutés soient gréffés à la panoplie de modules du noyau linux standard que l’on s’apprête à compiler … Est -ce qu’il y a un endroit où les placer pour que lors du make menuconfig, ils apparaissent dans la kyrielle d’options (et par defaut cochés [M] vu que dans l’ancien noyau ils étaient déjà en [M] ) ??

Ou bien est ce qu’il faut faire à la main copie des modules rajoutés de l’ancien noyau vers le nouveau dans /lib/modules aprés compilation du nouveau noyau ?


#17

Pas imprimé, mais bookmarké

Je dirais même mieux “scrapbooké” :smiley: [/i]


#18

:blush: j’ai donc encore dis une groosse boulette ?


#19

Non, mais ce que tu dis n’est pas clair. Les modules intègrés au noyau sont dans le noyau, et ceux qui n’y sont pas n’apparaissent pas dans le menuconfig de toutes les manières. Tu les compiles avec make-kpkg … modules, pour ceux qui sont sous forme de source debian, et avec une methode qui t’est specifiée avec ce que tu récupères, quand ce ne sont pas des sources debian…
Je ne comprends toujours pas ta question :laughing:


#20

Oui, alors peut-être que ce que j’essaye de d’exprimer relève plus de la création d’une nouvelle branche que d’une compilation :unamused:
Prenons un exemple bien concret, ben tiens, justement mon zd1211 pour le wifi :
1/ je vais compiler le dernier noyau stable linux …
2/ je pense avoir compris qu’il n’y a aucun moyen de faire apparaître le zd1211 dans mon menu du cofig du nouveau noyau …
3/ une fois la config sauvegardée, la compilation se lance d’elle-même,
donc je ne peut pas le mettre en dur dans le noyau pour l’instant (si tant est que c’est une bonne idée, ce dont je doute, mais certains modules ajoutés pourraient vouloir être mis en dur à juste titre non ? )
4/ Maintenant que fait le nouveau noyau, lui aussi il va se servir dans /lib/modules ?
5/ pourquoi les modules que chargeait l’ancien noyau ne peuvent pas apparaitre dans le menu de configuration du noyau ?

ps : si je pose que des boulettes, n’hésite pas à virer mes questions lol :wink: je veux pas répandre la confusion sur cet excellent topic :blush: