MODPROBE.D(5) modprobe.d MODPROBE.D(5) NOM modprobe.d - Repertoire de configurations pour modprobe SYNOPSIS /etc/modprobe.d/*.conf /run/modprobe.d/*.conf /usr/local/lib/modprobe.d/*.conf /usr/lib/modprobe.d/*.conf /lib/modprobe.d/*.conf DESCRIPTION Comme la commande modprobe peut ajouter ou supprimer plus d'un module, et a cause des modules qui ont des dependances, il y a eu besoin d'une methode pour specifier quelles options utiliser avec les modules.. Ils peuvent egalement etre utilises pour creer des alias pratiques : des noms alternatifs pour un module, ou ils peuvent remplacer le comportement normal de modprobe pour ceux qui ont des exigences particulieres (comme l'insertion de plus d'un module). Notez que les noms de module et d'alias (comme d'autres noms de modules) peuvent avoir les signes - ou _ dans leurs noms ; les deux sont interchangeables pour toutes les commandes sur les modules, la conversion du tiret bas etant automatique. FORMAT DE CONFIGURATION Les fichiers de configuration comprennent une commande par ligne, avec les lignes blanches et celles commencant par un croisillon # ignorees (ce qui est pratique pour ajouter des commentaires). Une contre-oblique \fP a la fin de la ligne la fait continuer sur la ligne suivante, ce qui rend ces fichiers un peu plus propres. Voir la section COMMANDES plus loin pour plus d'informations. REPERTOIRES DE CONFIGURATION ET PRIORITES Les fichiers de configuration sont lus a partir des repertoires listes dans SYNOPSIS dans cet ordre de preseance. Une fois qu'un fichier d'un nom donne est charge, tout fichier du meme nom dans les repertoires suivants est ignore. Tous les fichiers de configuration sont tries par ordre lexicographique, quel que soit le repertoire dans lequel ils se trouvent. Ces fichiers de configuration peuvent etre completement remplaces (en ayant un nouveau fichier de configuration portant le meme nom dans un repertoire de priorite plus elevee) ou remplaces partiellement (en ayant un fichier de configuration ordonne plus tard). NOTE : les repertoires de configuration peuvent etre modifies au moyen de la variable d'environnement MODPROBE_OPTIONS. Voir la section ENVIRONNEMENT dans modprobe(8). COMMANDES alias nom_aternatif nom_du_module Cette commande permet de donner un nom alternatif a un module. Par exemple : << alias mon_mod le_super_long_nom_de_module >> signifie que vous pouvez utiliser << modprobe mon_mod >> au lieu de << modprobe le_super_long_nom_de_module >>. Il est possible aussi d'utiliser les caracteres jokers de type interpreteur de commande, ainsi << alias mon_mod* le_super_long_nom_de_module >> signifie que << modprobe mon_mod_qqchose >> aura le meme effet. Il ne peut pas y avoir d'alias vers d'autres alias (cela menerait a la folie), mais les alias peuvent avoir des options qui seront ajoutees aux autres options. Notez que les modules peuvent aussi contenir leurs propres alias, ce qui est visible en utilisant modinfo. Ces alias ne sont utilises qu'en dernier ressort lorsque il n'y a pas reellement de module, de commande install, remove ou alias dans la configuration. blacklist nom_du_module Les modules peuvent contenir leurs propres alias : habituellement ce sont des alias decrivant le peripherique pris en charge, tel que << pci:123... >>. Ces alias << internes >> peuvent etre ecrases par des mots cles d' << alias >> habituels, mais il y a des cas ou deux ou plus modules prennent en charge les memes peripheriques, ou un module non valable declare prendre en charge un peripherique alors qu'il ne le fait pas : le mot cle blacklist indique que tous les alias << internes >> de ce module particulier sont ignores. install nom_du_module commande... Cette commande indique a modprobe d'executer votre commande au lieu d'ajouter le module au noyau comme normalement. La commande peut etre toute commande d'interpreteur : cela vous permet de faire autant de procedures complexes que vous le souhaitez. Par exemple, si le module << fred >> fonctionne mieux avec le module << barney >> deja installe, (mais qui n'est pas une dependance, donc modprobe ne le chargera pas automatiquement), vous pouvez taper << install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred >>, qui fera ce que vous voulez. Notez que l'option --ignore-install empechera le second modprobe d'executer encore la meme commande install. Voir aussi remove ci-dessous. L'avenir a long terme de cette commande en tant que solution au probleme de la fourniture de dependances de modules supplementaires n'est pas assure et il est prevu de remplacer cette commande par un avertissement quant a son eventuelle suppression ou obsolescence a un moment. Son utilisation complique la determination automatisee des dependances des modules par les utilitaires des distributions, tels que mkinitrd (car ils doivent maintenant interpreter d'une maniere ou d'une autre ce que les commandes install pourraient faire). Dans un monde parfait, les modules devraient fournir toutes les informations de dependances sans l'utilisation de cette commande et des travaux sont en cours pour implementer la prise en charge des dependances << soft >> dans le noyau Linux. L'utilisation de la chaine << $CMDLINE_OPTS >> entrainera son remplacement par toutes les options indiquees sur la ligne de commande de modprobe. Cela peut etre utile, car les utilisateurs s'attendent a ce que << modprobe fred opt=1 >> passe l'argument << opt=1 >> au module, meme s'il y a une commande install dans le fichier de configuration. Ainsi notre exemple ci-dessus devient << install fred /sbin/modprobe barney; /sbin/modprobe --ignore-install fred $CMDLINE_OPTS >>. options nom_de_module option... Cette commande permet d'ajouter des options au module nom_de_module (qui peut etre un alias) chaque fois qu'il est ajoute au noyau : soit directement (en utilisant modprobe nom_de_module) ou parce qu'un module qui a ete charge en depend. Toutes les options sont ajoutees ensemble, elles peuvent venir d'une option pour le module, pour un alias ou sur la ligne de commande. remove nom_de_module commande... Cette commande est similaire a la commande install ci-dessus, a part qu'elle est invoquee lors de l'execution de << modprobe -r >>. softdep nom_de_module pre: modules... post: modules... La commande softdep permet d'indiquer des dependances de module << soft >> ou optionnelles. nom_de_module peut etre utilise sans les modules optionnels installes, mais generalement il manque quelques fonctionnalites. Par exemple, un pilote pour un stockage HBA peut avoir besoin qu'un autre module soit charge pour utiliser toutes les fonctionnalites de gestion. Les modules << pre-deps >> et << post-deps >> sont des listes de noms et/ou d'alias d'autres modules que modprobe essaiera d'installer (ou de supprimer) dans l'ordre avant et apres le module principal donne dans l'argument nom_de_module. Exemple: Assumer que << softdep c pre: a b post: d e >> est fourni dans la configuration. Executer << modprobe c >> est maintement equivalent a << modprobe a b c d e >> sans les << softdep >>. Des arguments tels que --use-blacklist sont appliquees a tous les modules indiques, alors que les parametres du module ne s'appliquent qu'au module c. Note : s'il y a des commandes install ou remove avec le meme argument nom_de_module, softdep prend la preseance. weakdep nom_de_module modules... La commande weakdep permet de specifier les dependances faibles des modules. Elles sont similaires aux pre softdeps, avec la difference que l'espace utilisateur ne prevoit pas de charger cette dependance avant le module indique. A la place, le noyau doit en apeller une ou plusieurs durant l'essai du module, en fonction du materiel auquel il est lie. L'objectif du module faible est d'accepter qu'un pilote indique que certaines dependances peuvent etre necessaires, donc elles devraient etre presentes dans le systeme de fichier (par exemple dans initramfs) lorsque le module est essaye. Exemple : passer << weakdep c a b >>. Un programme creant un initramfs sait qu'il doit ajouter a, b et c au systeme de fichiers puisque a et b peuvent etre demandes/exiges au lancement. Lorsque c est charge et a ete eprouve, il peut lancer des appels request_module() entrainant a et b a etre aussi charges. COMPATIBILITE Une future version de kmod viendra avec un avertissement serieux pour empecher l'usage de la commande install comme explique ci-dessus. Cela arrivera lorsque la prise en charge des dependances << soft >> sera effective. Cette prise en charge ameliorera la prise en charge actuelle des softdeps par cet outil en fournissant de telles dependances directement dans le module. COPYRIGHT Cette page de manuel etait originellement sous copyright 2004, Rusty Russell, IBM Corporation. VOIR AUSSI modprobe(8), modules.dep(5) AUTEURS De nombreuses contributions proviennent de la liste de diffusion linux-modules et de Github. Si vous avez une copie de kmod.git lui-meme, les sorties de git-shortlog(1) et de git-blame(1) vous indiquerons les auteurs de certaines parties du projet. Lucas De Marchi est le responsable actuel du projet. TRADUCTION La traduction francaise de cette page de manuel a ete creee par bubu Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . kmod 26 aout 2024 MODPROBE.D(5)