Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] insmod - Charge des modules dans le noyau. .hy 0 [size=18] [b]Résumé[/b] [/size] [b]insmod[/b] [-fhkLmnpqrsSvVxXyYN] [-e [i]persist_name[/i]] [-o [i]module_name[/i]] [-O [i]blob_name[/i]] [-P [i]prefix[/i]] [i]module[/i] [ [b]symbol[/b]=[i]value[/i] ... ] [size=18] [b]Description[/b] [/size] [b]insmod[/b] charge un module dans le noyau en cours d'utilisation. [b]insmod[/b] essaie de lier un module dans le noyau en cours d'exécution en résolvant les noms de symboles à partir de la table des symboles exportés par le noyau. Si le nom du fichier objet est donné sans répertoire et sans extension, [b]insmod[/b] cherchera le module dans quelques répertoires par défaut. La variable d'environnement MODPATH peut surcharger ces répertoires par défaut. Si un fichier de configuration comme /etc/modules.conf existe, il surchargera les chemins indiqués dans [b]MODPATH[/b]. La variable d'environnement MODULECONF peut sélectionner un fichier de configuration différent de [i]/etc/modules.conf[/i] (ou [i]/etc/conf.modules[/i] (à éviter)). Cette variable d'environnement prévaudra sur toutes les définitions précédentes. Quand la variable d'environnement [b]UNAME_MACHINE[/b] est remplie, modutils l'utilisera à la place du champ "machine" de l'appel-système uname(). Ceci est surtout utile si vous compilez des modules 64 bits dans un espace utilisateur 32 bits ou inversement ; remplissez [b]UNAME_MACHINE[/b] avec le type de modules construits. La version actuelle de modutils ne supporte pas la construction croisée complète de modules, elle est limitée au choix entre 32 et 64 bits de l'architecture hôte. [b]Options[/b] [table][row][col]    [/col][col][b][/b]-e [i]persist_name[/i], [b][/b]--persist=[i]persist_name[/i] Indique où les données persistantes du modules doivent être lues au chargement et écrite lorsque cette instance du module est déchargée. Cette option est ignorée silencieusement si le module n'a pas de données persistantes. Les données persistantes ne sont lues par [b]insmod[/b] que si cette option est présente. Par défaut [b]insmod[/b] ne traite pas les données persistantes.[/col][/row][/table] [b][/b] [table][row][col]    [/col][col]Sous forme raccourcie, [b][/b]-e "" (une chaîne vide) est interprété par [b]insmod[/b] comme la valeur de [b]persistdir[/b] définie dans [i]modules.conf[/i], suivie du nom du fichier du module par rapport au chemin de recherche où il a été trouvé, en éliminant toute extension ".gz", ".o" ou ".mod". Si [b]modules.conf[/b] spécifie "[b]persistdir[/b] =" ([b]persistdir[/b] est un champ vide) alors ce raccourci est ignoré silencieusement. (Voir [b]modules.conf[/b] (5).)[/col][/row][/table] [b]-f , --force[/b] [table][row][col]    [/col][col]Tentera de charger un module même si la version du noyau en cours et celle pour laquelle le module a été compilé le module ne correspondent pas. Ceci ne surcharge que la vérification du numéro de noyau, et n'a aucun effet sur la vérification des noms de symbole. Si le nom d'un symbole du module ne correspond pas au noyau, il n'y a aucun moyen de forcer [b]insmod[/b] à le charger.[/col][/row][/table] [b]-h , --help[/b] [table][row][col]    [/col][col]Affiche une page d'aide et se termine.[/col][/row][/table] [b]-k , --autoclean [/b] [table][row][col]    [/col][col]Marque le module pour auto-nettoyage. Ceci permettra à [b]kerneld[/b](8) d'enlever les modules qui ne sont pas utilisés durant une certaine période - habituellement une minute.[/col][/row][/table] [b]-L , --lock [/b] [table][row][col]    [/col][col]Utiliser [b]flock[/b](2) pour empêcher deux chargements simultanés du même module.[/col][/row][/table] [b]-m , --map [/b] [table][row][col]    [/col][col]Affiche la carte de chargement, rendant plus facile le débogage en cas de panique du noyau.[/col][/row][/table] [b]-n , --noload[/b] [table][row][col]    [/col][col]Fausse exécution. Tout faire, mais ne rien charger dans le noyau. Avec option [b][/b]-m ou [b][/b]-O, l'exécution produira les fichiers carte ou blob. Comme le module n'est pas chargé, l'adresse réelle du noyau est inconuue, ainsi les fichiers utilisent une adresse de chargement arbitraire 0x12340000.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-o [i]module_name[/i], [b][/b]--name=[i]module_name[/i] Indique explicitement le nom du module, plutôt que d'utiliser le celui déduit du fichier objet.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-O [i]blob_name[/i], [b][/b]--blob=[i]blob_name[/i] Sauver le fichier objet dans [i]blob_name[/i]. Le résultat est un blob binaire (pas d'en-tête ELF) montrant exactement ce qui est chargé dans noyau après manipulation et déplacemen des sections. L' option [b][/b]-m est recommandée pour obtenir une carte de cet objet.[/col][/row][/table] [b]-p , --probe[/b] [table][row][col]    [/col][col]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. Elle ne vérifie pas les déplacements et ne produit pas de fichier blob.[/col][/row][/table] [table][row][col]    [/col][col][b][/b]-P [i]prefix[/i], [b][/b]--prefix=[i]prefix[/i] Cette option sert pour les modules avec numéros de version, et les noyaux smp ou bigmem, car ces modules ont un préfixe supplémentaire ajouté aux noms des symboles. Si le noyau a été construit avec les numéros de versions pour les symboles, alors [b]insmodfP[/b] extraiera automatiquement le préfixé de la définition de "get_module_symbol" ou "inter_module_get", l'un des deux doit exister dans tous les noyaux qui supportent les modules. Si le noyau n'a pas de version pour les symboles, mais que le module en a, alors l'utilisateur doit fournir l'option [b]-P .[/b][/col][/row][/table] [b]-q , --quiet[/b] [table][row][col]    [/col][col]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 [b]insmod[/b].[/col][/row][/table] [b]-r , --root[/b][/col][/row][/table] [b][/b] [table][row][col]    [/col][col]Certains utilisateurs compilent les modules sans droits root et les installent en étant root. Ceci risque de créer 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.[/col][/row][/table] [b][/b] [table][row][col]    [/col][col]Par défaut, modutils rejettera les demandes d'utilisation d'un module qui n'appartient à root. L'option [b]-r[/b] supprimera l'erreur et autorisera le chargement de module n'appartenant pas à root. [b]Note[/b] : la valeur par défaut pour la vérification d'appartenance à root peut être modifiée dans la configuration de modutils.[/col][/row][/table] [i][/i] [table][row][col]    [/col][col][b]L'utilisation[/b] de -r ou la configuration "pas de vérification root" est un danger pour la sécurité et est déconseillée.[/col][/row][/table] [b]-s , --syslog[/b] [table][row][col]    [/col][col]Envoie les messages à [b]syslog[/b](3) plutôt que sur le terminal.[/col][/row][/table] [b]-S , --kallsyms[/b] [table][row][col]    [/col][col]Force le module chargé à avoir des données [b]kallsyms[/b], même si le noyau ne le supporte pas. Cette option sert sur les petits systèmes où le noyau est chargé sans données [b]kallsyms[/b], mais que les modules ont besoin de [b]kallsyms[/b] pour le débogage. Configuration par défaut sur Red Hat Linux.[/col][/row][/table] [b]-v , --verbose[/b] [table][row][col]    [/col][col]Rends insmod plus volubile.[/col][/row][/table] [b]-V , --version[/b] [table][row][col]    [/col][col]Affiche le numéro de version de [b]insmod[/b].[/col][/row][/table] [b]-X , --export ; -x , --noexport[/b] [table][row][col]    [/col][col]Respectivement, exporter ou non tous les symboles externes du module. La valeur par défaut est l'exportation des symboles. Cette noption n'est effective que si le module n'exporte pas explicitement sa propre table de symbole, ce qui est déconseillé.[/col][/row][/table] [b]-Y , --ksymoops ; -y , --noksymoops[/b] [table][row][col]    [/col][col]Respectivement ajoute ou non les symboles ksymoops à ksyms. Ces symboles servent à ksymoops pour aider au débogage si il y a un problème (Oops) dans le module. La valeur par défaut est de définir les symboles [b]ksymoops[/b]. Cette option est indépendante de [b][/b]-X/[b][/b]-x.[/col][/row][/table] [b][/b] [table][row][col]    [/col][col]Les symboles [b]ksymoops[/b] ajoutent environ 260 octets par module chargé. À moins d'être vraiment à court de mémoire pour le noyau et de tenter de réduire ksyms au minimum, utilisez la configuration par défaut pour être plus à l'aise au débogage. Les symboles [b]ksymoops[/b] sont nécessaires pour la sauvegarde de données persistantes de modules.[/col][/row][/table] [b]-N , --numeric-only[/b] [table][row][col]    [/col][col]Ne vérifie que la partie numérique de la version du module par rapport à celle du noyau, c'est-à-dire ignore le suffixe EXTRAVERSION pour savoir si le module appartient au noyau. Cette option est automatiquement active pour les noyaux à partir du 2.5, et optionnel pour les précédents.[/col][/row][/table] [b]ParamÈtres des modules[/b] Des modules acceptent des paramètres au chargement pour adapter leur action. Ces paramètres sont souvent des ports E/S et des numéros d'IRQ variant d'une machine à l'autre et ne peuvent être déterminés à partir du matériel. Dans les modules pour les noyau 2.0, tout symbole d'entier ou de pointeur caractère peut être manipulé comme un paramètre et être modifié. Depuis les noyaux 2.1, les symboles sont explicitement marqués comme des paramètres, afin que seules des données spécifiques soient modifiables. De plus le type est indiqué pour vérifier la valeur fournie au chargement. Pour les entiers, les valeurs peuvent être en base 10, 8 ou 16, comme en C : 17, O21 ou Ox11. Les éléments de tableau sont fournis en séquence, séparés par des virgules. Des éléments peuvent être `sautés' en omettant leur valeur. Dans les modules 2.0, les valeurs ne débutant pas par un nombre sont considérées comme des chaînes. Depuis les 2.1, l'information sur le type de paramètre indique si la valeur doit être considérée comme une chaîne. Si la valeur commence par un guillemet ([b]"[/b]), la chaîne est interprétée comme en C, avec séquence d'échappement et le reste. Notez que depuis la ligne de commande du shell, les guillemets doivent être protégés pour éviter leur interprétation par ce dernier. [b]Symboles et modules sous licence gpl[/b] Depuis le noyau 2.4.10, les modules doivent avoir une chaîne indiquant leur licence, définie par [b]MODULE_LICENSE()[/b]. Plusieurs chaînes sont reconnues comme étant compatibles GPL, tout autre chaîne de licence ou l'absence de licence est considérée comme propriétaire. Voir [i]include/linux/module.h[/i] pour une liste des chaînes compatibles GPL. Si le noyau supporte l'attribut [i]/proc/sys/kernel/tainted[/i], alors [b]insmod[/b] fera un OU entre l'attribut et '1' au chargement d'un module sans licence GPL. Un avertissement sera affiché si le noyau supporte le mode taché (tainted) et qu'on charge un module sans licence. Un avertissement est fourni pour tout module ayant [b]MODULE_LICENSE()[/b] non compatible GPL, même sur les noyaux anciens ne supportant pas l'entachement. Ceci limite les avertissements quand les modutils récents sont utilisés sur des noyaux anciens. Le mode [b]insmod[/b] -f (force) fera un OU entre l'attribut tainted et '2' sur les noyaux supportant l'entachment. Ceci déclenche toujours un avertissement. Certains développeurs du noyau réclament que les symboles exportés par leur code ne soit utilisés que dans des modules avec une licence compatible GPL. Ces symboles sont exportés avec [b]EXPORT_SYMBOL_GPL[/b] plutôt qu'avec le normal [b]EXPORT_SYMBOL[/b]. Les symboles GPL-seulement exportés par le noyau et d'autres modules ne sont visibles que des modules ayant une licence compatible GPL. Ils apparaissent dans [i]/proc/ksyms[/i] avec le préfixe '[b]GPLONLY_[/b]'. [b]insmod[/b] ignore le préfixe [b]GPLONLY_[/b] des symboles en chargeant un module avec une licence compatible GPL, afin que le module fasse référence au nom du symbole sans le préfixe. Les symboles GPL-seulement ne sont pas rendus disponibles aux modules sans licence compatible GPL, ou sans licence indiquée. [b]Aide ksymoops[/b] Pour aider au débogage des problèmes du noyau avec des modules, [b]insmod[/b] ajoute par défaut des symboles dans ksyms, voir l'option [b]-Y[/b]. Ces symboles débutent avec [b]__insmod_modulename_[/b]. Le [i]modulename[/i] est nécessaire pour rendre les symboles uniques, il est possible de charger le même objet plusieurs fois sous différents noms de modules. Actuellement les commandes définies sont : [b]__insmod_modulename_Oobjectfile_Mmtime_Vversion[/b] [table][row][col]    [/col][col][i]objectfile[/i] est le nom du fichier depuis lequel l'objet a été chargé. Ceci garanti que ksymoops peut accéder correctement au code de l'objet. [i]mtime[/i] est l'horodatage en hexadécimal de la dernière modification du fichier en hexadécimal, zéro si [b]stat[/b](2) a échoué. [i]version[/i] est la version du noyau pour lequel le module a été compilé, -1 si la version n'est pas disponible. Le symbole _0 est l'adresse de début de l'en-tête du module.[/col][/row][/table] [b]__insmod_modulename_Ssectionname_Llength[/b] [table][row][col]    [/col][col]Ce symbole apparaît au début des sections ELF sélectionnées, actuellement .text, .rodata, .data .bss, et .sbss. Elle apparaît seulement si la section a une taille non-nulle. [i]sectionname[/i] est le nom de la section ELF, [i]length[/i] est la longueur en décimal de la section. Ces symboles aident ksymoops à déterminer les adresses des sections dans lesquelles aucun symbole n'est disponible.[/col][/row][/table] [b]__insmod_modulename_Ppersistent_filename[/b] [table][row][col]    [/col][col]Créé par [b]insmod[/b] seulement si le module a un ou plusieurs paramètres qui sont marqués comme données persistantes, et si un fichier de sauvegarde (voir[b][/b]-e, plus haut) est disponible.[/col][/row][/table] L'autre problème avec le débogage des problèmes du noyau dans les modules est que le contenu de [i]/proc/ksyms[/i] et [i]/proc/modules[/i] peut changer entre l'instant du Oops et le moment où vous analysez le fichier journal. Pour pallier ce problème, si le répertoire [i]/var/log/ksymoops[/i] existe alors [b]insmod[/b] et [b]rmmod[/b] copieront automatiquement [i]/proc/ksyms[/i] et [i]/proc/modules[/i] dans [i]/var/log/ksymoops[/i] avec le préfixe `date +%Y%m%d%H%M%S`. L'administrateur système peut indiquer à ksymoops quel fichier employer pour déboguer un Oops. Il n'y a pas d'option pour désactiver cette copie automatique, si vous ne voulez pas qu'elle se produise, il ne faut pas créer de répertoire [i]/var/log/ksymoops[/i]. Si le répertoire existe, il doit appartenir à root, avoir le mode 644 ou 600 et vous devriez lancer chaque jour le script suivant, installé comme [b]insmod_clean_ksymoops[/b]. .ne 8 .nf #!/bin/sh # Supprime la sauvegarde de ksyms et des modules sans accès depuis 2 jours if [ -d /var/log/ksymoops ] then set -e # S'assurer qu'il y en a toujours au moins une 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 [size=18] [b]Voir aussi[/b] [/size] [b]rmmod (8), [/b] [b]modprobe (8), [/b] [b]depmod (8), [/b] [b]lsmod (8),[/b] [b]ksyms (8),[/b] [b]modules (2),[/b] [b]genksyms (8), [/b] [b]kerneld (8),[/b] [b]ksymoops (noyau).[/b] [size=18] [b]Historique[/b] [/size] Le support des modules a été conçu par Illustre Anonyme [b][/b] La version initiale pour Linux a été faite par Bas Laarhoven <bas@vimec.nl> [b][/b] La version 0.99.14 a été faite par Jon Tombs <jon@gtex02.us.es> [b][/b] Complétée par Bjorn Ekwall <bj0rn@blox.se> [b][/b] Aide ELF originelle de Eric Youngdale <eric@aib.com> [b][/b] Réécrite pour 2.1.17 par Richard Henderson <rth@tamu.edu> [b][/b] Complétée par Bjorn Ekwall <bj0rn@blox.se> pour modutils-2.2.*, Mars 1999 [b][/b] Support pour ksymoops par Keith Owens <kaos@ocs.com.au>, Mai 1999 [b][/b] Mainteneur actuel : Keith Owens <kaos@ocs.com.au>. [size=18] [b]Traduction[/b] [/size] Jérome Signouret, 2000. [b][/b] Christophe Blaess, 2003.
Fichier