Service de noyau kmod_load

Objectif

Charge un fichier objet dans le noyau ou des requêtes pour un fichier objet déjà chargé.

Syntaxe

#include <sys/ldr.h> #include <sys/types.h> #include <sys/errno.h> int kmod_load (pathp, flags,libpathp, kmidp) caddr_t pathp; uint flags; caddr_t libpathp; mid_t * kmidp;

Paramètres

Article	Descriptif
Chemin	Pointe vers une chaîne de caractères contenant le chemin-nom du fichier objet à charger ou à interroger.
Flags	Indique un ensemble d'options de chargeur décrivant les options du chargeur à appeler. Les indicateurs suivants sont définis: CHEMIN_D_USAGE_LOGIQUE Les chaînes de caractères pointé par les paramètres Chemin et Libpathp se trouvent dans l'espace adresse utilisateur. Si l'indicateur CHEMIN_D_USAGE_LOGIQUE n'est pas défini, les chaînes de caractères sont supposées être dans le noyau ou le système, espace. LD_KERNELEX Place les symboles exportés de ce fichier objet dans l'espace de nom /usr/lib/boot/unix . Les fichiers d'objets supplémentaires chargés en raison de la résolution des symboles pour le fichier spécifié n'ont pas leurs symboles exportés dans l'espace des noms de noyau. LD_SINGLELOAD Lorsque cette option est définie, le fichier objet spécifié par le paramètre Chemin est chargé dans le noyau uniquement si un fichier d'objet portant le même nom de chemin n'a pas déjà été chargé. Si un fichier d'objet portant le même nom de chemin a déjà été chargé, son ID de module est renvoyé (à l'aide du paramètre Kmidp ) et son nombre de chargement est incrémenté. Si le fichier objet n'est pas encore chargé, ce service effectue la charge comme si le drapeau n'était pas défini. Cette option est utile pour prendre en charge les routines de noyau globales où une seule copie de la routine et ses données peuvent être présentes. Généralement, les routines qui exportent des symboles à ajouter à l'espace de nom du noyau sont de ce type. Remarque: Une comparaison de nom de chemin est effectuée pour déterminer si le même fichier objet a déjà été chargé. Ce service chargera par erreur une nouvelle copie du fichier objet dans le noyau si le chemin d'accès au fichier objet est exprimé différemment qu'il ne l'était lors d'une demande de chargement précédente. Si ni cet indicateur, ni l'indicateur LD_REQUÊTE n'est défini, ce service charge une nouvelle copie du fichier objet dans le noyau. Cela se produit même si d'autres copies du fichier objet ont déjà été chargées. LD_REQUÊTE Cette option indique qu'une opération de requête détermine si le fichier objet spécifié par le paramètre Chemin est chargé. S'il n'est pas chargé, un ID de module de noyau 0 est renvoyé à l'aide du paramètre Kmidp . Sinon, l'ID module noyau affecté au fichier objet est renvoyé. Si plusieurs instances de ce fichier ont été chargées dans le noyau, l'ID du module de noyau du dernier fichier objet chargé est renvoyé. Le paramètre Libpathp n'est pas utilisé pour cette option. Remarque: Une comparaison de nom de chemin est effectuée pour déterminer si le même fichier objet a été chargé. Ce service retournera à tort un`not loaded`Si le nom de chemin d'accès au fichier objet est exprimé différemment qu'il ne l'était lors d'une demande de chargement précédente. Si cette option est définie, aucun fichier objet n'est chargé et les indicateurs LD_SINGLELOAD et LD_KERNELEX sont ignorés, s'ils sont définis.
Libpathp	Pointe vers une chaîne de caractères contenant le chemin de recherche à utiliser pour trouver les fichiers d'objets requis pour terminer la résolution des symboles pour cette charge. Si le paramètre est null, le chemin de recherche est défini à partir de la spécification dans l'en-tête du fichier objet pour le fichier objet spécifié par le paramètre Chemin .
Kmidp	Pointe vers une zone où l'ID module noyau associé à cette charge du module spécifié doit être renvoyé. Les données de cette zone ne sont pas valides si le service Kmod_load renvoie un code retour différent de zéro.

Descriptif

Le service de noyau Kmod_load charge dans le noyau un fichier d'objet d'extension de noyau spécifié par le paramètre Chemin . Ce service renvoie un ID module de noyau pour cette instance du module.

Vous pouvez spécifier des indicateurs pour demander une seule charge, ce qui garantit qu'une seule copie du fichier objet est chargée dans le noyau. Une autre option consiste simplement à rechercher un fichier d'objet donné (spécifié par nom-chemin). Cela permet à l'utilisateur de déterminer si un module est déjà chargé et d'accéder à son ID module de noyau.

Le service Kmod_load fournit également la résolution du symbole de temps de chargement des symboles importés du module chargé. Le service Kmod_load charge des modules d'objet de noyau supplémentaires si nécessaire pour la résolution des symboles.

Support de liaison de symbole de chargeur

Les symboles importés depuis l'espace de nom du noyau sont résolus avec des symboles qui existent dans l'espace de nom du noyau au moment de la charge. (Les symboles sont importés à partir de l'espace de nom du noyau en spécifiant la chaîne de caractères #!/unix comme première zone d'une liste d'importation lors de l'édition de liens.)

Les modules de noyau peuvent également importer des symboles à partir d'autres modules d'objet de noyau. Ces autres modules d'objet noyau sont chargés avec le module d'objet spécifié s'ils sont nécessaires pour résoudre les symboles importés.

Tous les symboles exportés par le module d'objet de noyau spécifié sont ajoutés à l'espace de nom du noyau si le paramètre Indicateurs est défini par l'indicateur LD_KERNELEX . Cela rend les symboles disponibles pour d'autres modules d'objet de noyau chargés par la suite. Les modules d'objets du noyau chargés pour le compte du module d'objet de noyau spécifié (pour résoudre les symboles importés) n'ont pas leurs symboles exportés ajoutés à l'espace de nom du noyau.

Les symboles d'exportation du noyau spécifiés (heure d'édition des liens) avec le mot clé SYSCALL dans la liste d'exportation du module principal sont ajoutés à la table des appels système. Ces symboles d'exportation de noyau sont disponibles pour les programmes d'application en tant qu'appels système.

Recherche de modules d'objets partagés pour la résolution des références de symbole

La chaîne de recherche de chemin de recherche est effectuée à partir de l'en-tête du module d'objet spécifié par le paramètre Chemin si le paramètre Libpathp a la valeur null. L'en-tête de module du module d'objet spécifié par le paramètre Chemin est utilisé.

Si l'en-tête du module contient un nom de fichier de base non qualifié pour le symbole (pas / [ barre oblique ] dans le nom), une chaîne de recherche est utilisée pour trouver l'emplacement du module d'objet partagé requis pour résoudre l'importation. Cette chaîne de recherche peut être tirée de l'un des deux endroits. Si le paramètre Libpathp de l'appel au service Kmod_load n'est pas null, il pointe vers une chaîne de caractères spécifiant le chemin de recherche à utiliser. Toutefois, si le paramètre Libpathp a la valeur null, le chemin de recherche doit être pris à partir de l'en-tête du module pour le module d'objet spécifié par le paramètre Chemin .

La spécification du chemin de recherche trouvée dans les modules d'objet chargés pour résoudre les symboles importés n'est pas utilisée. Le service du chargeur de noyau ne prend pas en charge la résolution des symboles différés. Le chargement du module de noyau s'arrête avec une erreur si des symboles importés ne peuvent pas être résolus.

Environnement d'exécution

Le service de noyau Kmod_load peut être appelé à partir de Environnement de processus uniquement.

Valeurs renvoyées

Si le fichier objet est chargé sans erreur, l'ID module est renvoyé à l'emplacement désigné par le paramètre Kmidp et le code retour est défini sur 0.

Codes d'erreur

Si une erreur se produit, le module n'est pas chargé et aucun ID module de noyau n'est renvoyé. Le code retour est défini sur l'une des valeurs de retour suivantes:

Valeur renvoyée	Descriptif
EACCES	Indique qu'un module d'objet à charger n'est pas un fichier ordinaire ou que le mode du fichier de module d'objet refuse l'accès en lecture seule.
EACCES	Le droit de recherche est refusé sur un composant du préfixe de chemin.
EDÉFAUT	Indique que le processus appelant ne dispose pas des droits suffisants pour accéder à la zone de données décrite par les paramètres Chemin ou Libpathp lorsque l'indicateur CHEMIN_D_USAGE_LOGIQUE est défini. Ce code d'erreur est également renvoyé si une erreur d'E-S se produit lors de l'accès aux données dans cette zone.
ENOEXEC	Indique que le fichier programme possède les droits d'accès appropriés, mais qu'un indicateur XCOFF n'est pas valide dans son en-tête. Le service de noyau Kmod_load prend en charge le chargement des fichiers objet XCOFF (Extended Common Object File Format) uniquement. Ce code d'erreur est également renvoyé si le chargeur ne parvient pas à résoudre un symbole importé.
EINVAL	Indique que le fichier programme possède un indicateur XCOFF valide dans son en-tête, mais que l'en-tête est endommagé ou incorrect pour la machine sur laquelle le fichier doit être chargé.
ENOMEM	Indique que la charge nécessite plus de mémoire de noyau que celle autorisée par le maximum imposé par le système.
ETXTBSY	Indique que le fichier objet est actuellement ouvert pour écriture par un processus.
ENOTDIR	Indique qu'un composant du préfixe de chemin n'est pas un répertoire.
ENOENT	Indique qu'aucun fichier ou répertoire de ce type n'existe ou que le chemin-nom n'a pas la valeur null.
ESTALE	Indique que le répertoire racine ou actuel de l'appelant se trouve dans un système de fichiers virtuel qui a été démonté.
ELOOP	Indique que trop de liens symboliques ont été rencontrés lors de la conversion du paramètre Chemin ou Libpathp .
ENAMETOOLONG	Indique qu'un composant d'un nom de chemin d'accès a dépassé 255 caractères, ou qu'un nom de chemin entier a dépassé les 1023 caractères.
EIO	Indique qu'une erreur d'E-S s'est produite pendant l'opération.