Provided by: manpages-fr-dev_3.57d1p1-1_all bug

NOM

       init_module, finit_module - Charger un module de noyau

SYNOPSIS

       int init_module(void *module_image, unsigned long len,
                       const char *param_values);

       int finit_module(int fd, const char *param_values,
                        int flags);

       Remarque : il n'existe pas de fonctions glibc autour de ces appels système ; consultez NOTES.

DESCRIPTION

       init_module()  charge  une image ELF dans l'espace du noyau, réalise toutes les réallocations de symboles
       nécessaires, initialise les paramètres du module aux valeurs fournies par l'appelant et  exécute  ensuite
       la fonction init du module. Cet appel système nécessite des droits.

       L'argument module_image pointe vers un tampon contenant l'image binaire à charger ; len indique la taille
       du tampon. L'image  du  module  devrait  être  une  image  ELF  valable,  construite  pour  le  noyau  en
       fonctionnement.

       L'argument  param_values  est  une  chaîne  contenant  une liste de valeurs, séparées par des espaces, de
       paramètres du module (définis dans le module en utilisant  module_param()  et  module_param_array()).  Le
       noyau analyse cette chaîne et initialise les paramètres indiqués. Toutes les spécifications de paramètres
       sont de la forme :

       nom[=valeur[,valeur...]]

       Le paramètre nom est un de ceux définis dans le module en utilisant module_param() (consultez le  fichier
       include/linux/moduleparam.h dans les sources du noyau Linux). Le paramètre valeur est facultatif pour les
       paramètres de type bool et invbool. Les valeurs des paramètres de tableau sont indiqués en liste, séparés
       par des virgules.

   finit_module()
       L'appel  système  finit_module()  est  comme  init_module(),  mais  lit  le  module à charger à partir du
       descripteur de fichier fd. Il est utile quand l'authenticité d'un module du noyau  peut  être  déterminée
       par  son  emplacement sur le système de fichiers. Dans les cas où c'est possible, la complication induite
       par la vérification cryptographique de modules signés pour déterminer leur authenticité peut être évitée.
       L'argument param_values est comme pour init_module().

       L'argument flags modifie l'opération de finit_module(). C'est un masque OU bit à bit de zéro ou plusieurs
       des attributs suivants.

       MODULE_INIT_IGNORE_MODVERSIONS
              Ignorer les hachages de version de symbole.

       MODULE_INIT_IGNORE_VERMAGIC
              Ignorer la version magique du noyau.

       Certaines vérifications de sécurité sont construites dans un module pour s'assurer  qu'il  correspond  au
       noyau  sur  lequel  il  est  chargé. Ces vérifications sont enregistrées quand le module est construit et
       utilisées quand le module est chargé. D'abord, le module enregistre une chaîne « vermagic » contenant  le
       numéro  de  version  du  noyau  et  les  fonctionnalités  principales (comme le type de microprocesseur).
       Ensuite, si le module a été construit avec  l'option  de  configuration  CONFIG_MODVERSIONS  activée,  un
       hachage  de version est enregistré pour chaque symbole que le module utilise. Ce hachage est basé sur les
       types de l'argument et la valeur de retour pour la fonction nommée par le symbole. Dans ce cas, le numéro
       de  version  du noyau dans la chaîne « vermagic » est ignoré, car les hachages de version de symbole sont
       supposés être suffisamment fiables.

       L'utilisation de l'attribut MODULE_INIT_IGNORE_VERMAGIC indique que la chaîne « vermagic » est à ignorer,
       et  l'attribut  MODULE_INIT_IGNORE_MODVERSIONS  indique  que  les  hachages  de version de symbole sont à
       ignorer. Si le noyau est construit pour  permettre  le  chargement  forcé  (c'est-à-dire  configuré  avec
       CONFIG_MODULE_FORCE_LOAD),  alors  le chargement continuera, sinon il échouera avec ENOEXEC comme attendu
       pour les modules malformés.

VALEUR RENVOYÉE

       Ces appels système renvoient 0 en cas de succès, ou -1 en cas d'échec, auquel cas errno contient le  code
       d'erreur.

ERREURS

       EBADMSG (depuis Linux 3.7)
              La signature du module est mal formatée.

       EBUSY  Délai dépassé en essayant de résoudre une référence de symbole par ce module.

       EFAULT Un  argument  d'adresse  faisait  référence  à  un  emplacement  en dehors de l'espace d'adressage
              accessible du processus.

       ENOKEY (depuis Linux 3.7
              La signature du module est incorrecte ou le noyau n'a pas de clef pour  ce  module.  Cette  erreur
              n'est  renvoyée  que si le noyau a été configuré avec CONFIG_MODULE_SIG_FORCE. Si le noyau n'a pas
              été configuré avec cette option, alors un module incorrect ou non  signé  corrompt  simplement  le
              noyau.

       ENOMEM Mémoire épuisée.

       EPERM  L'appelant  n'avait  pas  les droits (n'avait pas la capacité CAP_SYS_MODULE), ou le chargement de
              module est désactivé (consultez /proc/sys/kernel/modules_disabled dans proc(5)).

       Les erreurs supplémentaires suivantes peuvent survenir pour init_module().

       EEXIST Un module de ce nom est déjà chargé.

       EINVAL param_values est incorrect, ou certaines parties de  l'image  ELF  de  module_image  contient  des
              incohérences.

       ENOEXEC
              L'image binaire fournie dans module_image n'est pas une image ELF, ou est une image ELF incorrecte
              ou pour une autre architecture.

       Les erreurs supplémentaires suivantes peuvent survenir pour finit_module().

       EBADF  Le fichier indiqué par fd n'est pas ouvert en lecture.

       EFBIG  Le fichier indiqué par fd est trop gros.

       EINVAL flags n'est pas correct.

       ENOEXEC
              fd ne fait pas référence à un fichier ouvert.

       En plus des erreurs précédentes, si la fonction init du module est exécutée et renvoie une erreur,  alors
       init_module() ou finit_module() échoue et errno est définie à la valeur renvoyée par la fonction init.

VERSIONS

       finit_module() est disponible depuis Linux 3.8.

CONFORMITÉ

       init_module() et finit_module() sont spécifiques à Linux.

NOTES

       La glibc ne fournit pas de fonction autour de ces appels système ; utilisez syscall(2) pour les appeler.

       Des  renseignements  concernant  les  modules  chargés  sont  disponibles  dans /proc/modules et dans les
       arborescences de fichiers des sous-répertoires par module sous /sys/module.

       Consultez  le  fichier  include/linux/module.h  dans  les  sources  du  noyau  Linux  pour  obtenir   des
       renseignements de fond utiles.

   Linux 2.4 et antérieurs
       Dans Linux 2.4 et antérieurs, l'appel système init_module() était assez différent :

       #include <linux/module.h>

        int init_module(const char *name, struct module *image);

       (les  applications  en  espace  utilisateur  peuvent  détecter la versions de init_module() disponible en
       appelant query_module() ; ce dernier appel échoue avec l'erreur ENOSYS à partir de Linux 2.6)

       L'ancienne version de l'appel système charge l'image de module réallouée pointée par image dans  l'espace
       du  noyau  et  exécute  la  fonction  init  du  module. L'appelant doit fournir l'image réallouée (depuis
       Linux 2.6, l'appel système init_module() s'occupe de la réallocation).

       L'image du module commence avec une structure module suivie par du code et des données appropriés. Depuis
       Linux 2.2, la structure module est définie comme suit :

           struct module {
               unsigned long         size_of_struct;
               struct module        *next;
               const char           *name;
               unsigned long         size;
               long                  usecount;
               unsigned long         flags;
               unsigned int          nsyms;
               unsigned int          ndeps;
               struct module_symbol *syms;
               struct module_ref    *deps;
               struct module_ref    *refs;
               int                 (*init)(void);
               void                (*cleanup)(void);
               const struct exception_table_entry *ex_table_start;
               const struct exception_table_entry *ex_table_end;
           #ifdef __alpha__
               unsigned long gp;
           #endif
           };

       On  s'attend à ce que tous les champs pointeurs, à l'exception de next et refs, pointent vers l'intérieur
       du corps du module et qu'ils puissent  être  initialisés  de  manière  appropriée  pour  l'espace  noyau,
       c'est-à-dire relogés avec le reste du module.

VOIR AUSSI

       create_module(2), delete_module(2), query_module(2), lsmod(8), modprobe(8)

COLOPHON

       Cette page fait partie de la publication 3.57 du projet man-pages Linux. Une description du projet et des
       instructions    pour    signaler    des    anomalies    peuvent     être     trouvées     à     l'adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par
       l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>.

       Alain Portal <http://manpagesfr.free.fr/> (2006-2008).

       Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org>  ou  par
       un rapport de bogue sur le paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C
       <section> <page_de_man> ».