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.

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.

COLOPHON

Cette page fait partie de la publication 3.65 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 à <[email protected]> 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> ».