insmod − installe des modules chargeables du noyau.

insmod [−fkmpqrsxXvyY] [−P prefix] [−o module_name] object_file [ symbol=value ... ]

insmod installe un module chargeable dans le noyau en cours d’utilisation.

insmod essaie de lier un module dans le noyau en cours d’exécution par résolution de toutes les commandes provenant de la table d’export du noyau.

Si le nom du fichier objet est donné sans extension, insmod cherchera le module dans quelques répertoires par défaut. La variable d’environnement MODPATH peut être utilisée pour modifier ces répertoires par défaut. Si le fichier de configuration de modules comme /etc/modules.conf existe, il sera sera en pris en compte pour la recherche.
La variable d’environnement MODULECONF peut aussi être utilisée pour sélectionner un fichier de configuration différent de /etc/modules.conf (ou /etc/conf.modules (à éviter)). Cette variable d’environnement prévaudra sur toutes les définitions précédentes.

OPTIONS

-f

Tentera de charger un module même si la version du noyau en cours et la version du noyau pour lequel a été compilée le module ne correspond pas.

-k

Pose le drapeau auto-clean sur le module. Ce drapeau sera utilisé par kerneld(8) pour enlever les modules qui ne sont pas utilisés durant une certaine période - habituellement une minute.

-m

Affiche la carte de chargement, rendant plus facile le débogage en cas de ‘kernel panic’.

-o module_name

Nomme explicitement le module, plutôt que d’utiliser le nom dérivée de la base de noms du source du fichier objet.

-p

Vérifie si le module peut être chargé avec succès. Cela inclut la position du fichier objet dans le chemin des modules, la vérification des numéros de versions, et la résolution des commandes.

-q

Ne pas afficher la listes des commandes non résolues. Ne pas signaler les problèmes de numéros de versions. Les problèmes ne seront visibles que dans le statut de sortie de insmod.

-r

Quelques utilisateurs compilent les modules sans les droits root et les installent comme s’ils étaient root. Ce procédé peut engendrer des modules n’appartenant pas à root, même si le répertoire des modules est propriété du root. Si un tel compte utilisateur est piraté, un intrus peut modifier ces modules et les utiliser pour obtenir un accès root. Par défaut, modutils rejettera les demandes d’utilisation d’un module qui n’appartient au root. Spécifier -r supprimera l’erreur et autorisera le chargement des modules qui n’appartiennent pas au root. L’utilisation de -r est un danger pour la sécurité et n’est pas recommandée.

-s

Affiche tout dans syslog(3) comme dans un terminal.

-v

Rends insmod plus bavard.

-X, -x

Respectivement, exporte ou non les commandes des modules externes. Par défaut les commandes sont exportées. Cette option est prise en compte seulement si le module n’exporte pas explicitement sa propre table de contrôle des commandes, et cela est à éviter.

-Y, -y

Respectivement ajoute ou non les commandes ksymoops à ksyms. Ces commandes sont utilisées par ksymoops pour procurer un meilleur débogage si il y a un problème ([NdT] Oops : traduit par problème) dans ce module. Cette option est indépendante de -X/-x. Les commandes ksymoops ajoutent environ 260 octets par chargement de module. Si vous êtes à court de mémoire pour le noyau et que vous tentez de réduire ksyms au minimum, utilisez la configuration par défaut et soyez plus exact dans les problèmes de débogage.

-P prefix

Cette option peut être utilisé avec des versions de modules pour les noyau SMP, jusqu’à ce que les modules aient un ‘extra’ préfixe ajouté dans leur noms de commandes. Normalement insmod détecte ce cas spécial automatiquement, cependant cette option reste disponible pour des cas très particuliers.

PARAMÃTRES DES MODULES

Des modules acceptent des paramètres lors de leur chargement pour les adapter à la situation. Ces paramètres sont des ports I/O des numéros d’IRQ qui varient d’un machine à l’autre et ne peuvent être déterminés à partir du matériel.

Dans les modules faits pour les noyau 2.0, des entiers ou des pointeurs alphanumériques peuvent être traités comme des paramètres et être modifiés. A partir des version 2.1 de noyau, les pointeurs sont explicitement marqués comme des paramètres dont la valeur spécifique peut être modifiée. En outre, le type d’information est donné par vérification de la valeur transmise lors du chargement.

Dans le cas des entiers, toutes les valeurs peuvent être en base 10, 8 ou 16 et se présentent comme en C : 17, O21 ou Ox1A. Le tableau des éléments est spécifié par une séquence séparée par des virgules; des éléments peuvent être ‘sautés’ par omission de la valeur.

Dans les modules 2.0, les valeurs qui ne débutent pas par un nombre sont considérées comme des chaînes. Depuis la version 2.1, le paramètre du type d’information indique si on doit interpréter la valeur comme une chaîne. Si la valeur commence par un guillemet ("), la chaîne est interprétée comme en C, avec séquence d’échappement et le reste. Notez que comme pour le prompt, les guillemets doivent être protégés de l’interprétation par le shell.

ASSISTANCE DE KSYMOOPS

Pour l’assistance au débogage des problèmes du noyau lors de l’utilisation des modules, insmod, par défaut, ajoute des commandes à ksyms, voir l’option -Y. Ces commandes débutent avec __insmod_modulename_. Le modulename est nécessaire pour faire des commandes uniques, il est normal de charger le même objet plus d’une fois sous différents noms de modules. Couramment les commandes définies sont

__insmod_modulename_Oobjectfile_Mmtime_Vversion

objectfile est le nom du fichier de l’objet qui a été chargé. Il n’est pas prudent que ksymoops puisse accéder au code par l’objet correct. mtime est le dernier ‘timestamp’ modifié pour le fichier en hexadécimal, zéro si l’état a échoué. version est la version du noyau pour lequel le module a été compilé, -1 si la version n’est pas disponible. La commande _0 est la même adresse de départ que celle de l’entête du module.

__insmod_modulename_Ssectionname_Llength

Cette commande apparaît au début des sections ELF sélectionnées, couramment .text, .rodata, .data et .bss. Elle apparaît seulement si la section a une taille différente de zéro sectionname est le nom de la section ELF, length est la longueur de la section en base dix. Ces commandes aident la carte des adresses de ksymoops pour les sections quand les commandes ne sont pas disponibles.

L’autre problème avec le débogage des problèmes du noyau dans les modules est que le contenu de /proc/ksums et de /proc/modules peut changer entre le moment du problème et le moment où vous écrivez le fichier de log. Pour aider à prévenir cette difficulté, si le répertoire /var/log/ksymoops existe alors insmod et rmmod copieront automatiquement /proc/ksyms et /proc/modules dans /var/log/ksymoops avec le préfixe ‘date +%Y%m%d%H%M%S‘. L’administrateur système peut appeler ksymoops qui produit des fichiers instantanément pour débloquer un problème. Il n’y a pas d’option pour désactiver cette copie automatique, si vous ne voulez pas que cela se produise, il ne faut pas créer de répertoire /var/log/ksymoops. Si le répertoire existe, il doit appartenir à root, avoir le mode 644 ou 600 et vous devez lancer le script chaque jour. Le script suivant est installé comme insmod_clean_ksymoops.

  #!/bin/sh
  # Supprime la sauvegarde de ksyms et les modules qui n’ont pas eu d’accès depuis 2 jours
  if [ -d /var/log/ksymoops ]
  then

set -e

# Make sure there is always at least one version

# Il faut être que c’est toujours la meilleure version

d=‘date +%Y%m%d%H%M%S‘

cp -a /proc/ksyms /var/log/ksymoops/${d}.ksyms

cp -a /proc/modules /var/log/ksymoops/${d}.modules

find /var/log/ksymoops -type f -atime +2 -exec rm {} \;

fi

rmmod(8), modprobe(8), depmod(8), lsmod(8), ksyms(8), modules(2), genksyms(8), kerneld(8), ksymoops(9).

Le support des modules a été conçu en premier par Anonyme
La version initiale pour Linux a été faite par Bas Laarhoven <bas@vimec.nl>
La version 0.99.14 a été faite par Jon Tombs <jon@gtex02.us.es>
Complétée par Bjorn Ekwall <bj0rn@blox.se>
Aide ELF originelle de Eric Youngdale <eric@aib.com>
Réécrite pour 2.1.17 par Richard Henderson <rth@tamu.edu>
Complétée par Bjorn Ekwall <bj0rn@blox.se> pour modutils-2.2.*, Mars 1999
Support pour ksymoops par Keith Owens <kaos@ocs.com.au>, Mai 1999

Jérome Signouret, 2000.