]>
Commit | Line | Data |
---|---|---|
5173e8e8 LDM |
1 | <?xml version="1.0"?> |
2 | <!--*-nxml-*--> | |
3 | <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> | |
4 | <refentry id="modprobe.d"> | |
5 | <refentryinfo> | |
6 | <title>modprobe.d</title> | |
7 | <productname>kmod</productname> | |
8 | ||
9 | <authorgroup> | |
10 | <author> | |
11 | <contrib>Developer</contrib> | |
12 | <firstname>Jon</firstname> | |
13 | <surname>Masters</surname> | |
14 | <email>jcm@jonmasters.org</email> | |
15 | </author> | |
16 | <author> | |
17 | <contrib>Developer</contrib> | |
18 | <firstname>Robby</firstname> | |
19 | <surname>Workman</surname> | |
20 | <email>rworkman@slackware.com</email> | |
21 | </author> | |
22 | <author> | |
23 | <contrib>Developer</contrib> | |
24 | <firstname>Lucas</firstname> | |
25 | <surname>De Marchi</surname> | |
2726da57 | 26 | <email>lucas.de.marchi@gmail.com</email> |
5173e8e8 LDM |
27 | </author> |
28 | </authorgroup> | |
29 | </refentryinfo> | |
30 | ||
31 | ||
32 | <refmeta> | |
33 | <refentrytitle>modprobe.d</refentrytitle> | |
34 | <manvolnum>5</manvolnum> | |
35 | </refmeta> | |
36 | ||
37 | <refnamediv> | |
38 | <refname>modprobe.d</refname> | |
39 | <refpurpose>Configuration directory for modprobe</refpurpose> | |
40 | </refnamediv> | |
41 | ||
42 | <refsynopsisdiv> | |
eecdcf2e | 43 | <para><filename>/lib/modprobe.d/*.conf</filename></para> |
5173e8e8 LDM |
44 | <para><filename>/etc/modprobe.d/*.conf</filename></para> |
45 | <para><filename>/run/modprobe.d/*.conf</filename></para> | |
46 | </refsynopsisdiv> | |
47 | ||
48 | <refsect1><title>DESCRIPTION</title> | |
49 | <para>Because the <command>modprobe</command> command can add or | |
50 | remove more than one module, due to modules having dependencies, | |
51 | we need a method of specifying what options are to be used with | |
52 | those modules. All files underneath the | |
53 | <filename>/etc/modprobe.d</filename> directory which end with the | |
54 | <filename>.conf</filename> extension specify those options as | |
55 | required. They can also be used to create convenient aliases: | |
56 | alternate names for a module, or they can override the normal | |
57 | <command>modprobe</command> behavior altogether for those with | |
58 | special requirements (such as inserting more than one module). | |
59 | </para> | |
60 | <para> | |
61 | Note that module and alias names (like other module names) can | |
9be0162f | 62 | have - or _ in them: both are interchangeable throughout all the |
5173e8e8 LDM |
63 | module commands as underscore conversion happens automatically. |
64 | </para> | |
65 | <para> | |
aca61d37 | 66 | The format of files under <filename>modprobe.d</filename> is |
5173e8e8 LDM |
67 | simple: one command per line, with blank lines and lines starting |
68 | with '#' ignored (useful for adding comments). A '\' at the end | |
69 | of a line causes it to continue on the next line, which makes the | |
70 | file a bit neater. | |
71 | </para> | |
72 | </refsect1> | |
73 | ||
74 | <refsect1><title>COMMANDS</title> | |
75 | <variablelist> | |
76 | <varlistentry> | |
77 | <term>alias <replaceable>wildcard</replaceable> <replaceable>modulename</replaceable> | |
78 | </term> | |
79 | <listitem> | |
80 | <para> | |
81 | This allows you to give alternate names for a module. For example: | |
82 | "alias my-mod really_long_modulename" means you can use "modprobe | |
83 | my-mod" instead of "modprobe really_long_modulename". You can also | |
84 | use shell-style wildcards, so "alias my-mod* | |
85 | really_long_modulename" means that "modprobe my-mod-something" has | |
86 | the same effect. You can't have aliases to other aliases (that way | |
87 | lies madness), but aliases can have options, which will be added to | |
88 | any other options. | |
89 | </para> | |
90 | <para> | |
91 | Note that modules can also contain their own aliases, which you can | |
92 | see using <command>modinfo</command>. These aliases are used as a | |
93 | last resort (ie. if there is no real module, | |
94 | <command>install</command>, <command>remove</command>, or | |
95 | <command>alias</command> command in the configuration). | |
96 | </para> | |
97 | </listitem> | |
98 | </varlistentry> | |
99 | <varlistentry> | |
100 | <term>blacklist <replaceable>modulename</replaceable> | |
101 | </term> | |
102 | <listitem> | |
103 | <para> | |
104 | Modules can contain their own aliases: usually these are aliases | |
105 | describing the devices they support, such as "pci:123...". These | |
106 | "internal" aliases can be overridden by normal "alias" keywords, | |
107 | but there are cases where two or more modules both support the same | |
108 | devices, or a module invalidly claims to support a device that it | |
109 | does not: the <command>blacklist</command> keyword indicates that | |
110 | all of that particular module's internal aliases are to be ignored. | |
111 | </para> | |
112 | </listitem> | |
113 | </varlistentry> | |
114 | <varlistentry> | |
115 | <term>install <replaceable>modulename</replaceable> <replaceable>command...</replaceable> | |
116 | </term> | |
117 | <listitem> | |
118 | <para> | |
119 | This command instructs <command>modprobe</command> to run your | |
120 | command instead of inserting the module in the kernel as normal. | |
121 | The command can be any shell command: this allows you to do any | |
122 | kind of complex processing you might wish. For example, if the | |
123 | module "fred" works better with the module "barney" already | |
124 | installed (but it doesn't depend on it, so | |
125 | <command>modprobe</command> won't automatically load it), you could | |
126 | say "install fred /sbin/modprobe barney; /sbin/modprobe | |
127 | --ignore-install fred", which would do what you wanted. Note the | |
128 | <option>--ignore-install</option>, which stops the second | |
129 | <command>modprobe</command> from running the same | |
130 | <command>install</command> command again. See also | |
131 | <command>remove</command> below. </para> <para>The long term | |
132 | future of this command as a solution to the problem of providing | |
133 | additional module dependencies is not assured and it is intended to | |
134 | replace this command with a warning about its eventual removal or | |
135 | deprecation at some point in a future release. Its use complicates | |
136 | the automated determination of module dependencies by distribution | |
137 | utilities, such as mkinitrd (because these now need to somehow | |
138 | interpret what the <command>install</command> commands might be | |
139 | doing. In a perfect world, modules would provide all dependency | |
140 | information without the use of this command and work is underway to | |
141 | implement soft dependency support within the Linux kernel. </para> | |
142 | <para> If you use the string "$CMDLINE_OPTS" in the command, it will | |
143 | be replaced by any options specified on the modprobe command line. | |
144 | This can be useful because users expect "modprobe fred opt=1" to | |
145 | pass the "opt=1" arg to the module, even if there's an install | |
146 | command in the configuration file. So our above example becomes | |
147 | "install fred /sbin/modprobe barney; /sbin/modprobe | |
148 | --ignore-install fred $CMDLINE_OPTS" | |
149 | </para> | |
150 | </listitem> | |
151 | </varlistentry> | |
152 | <varlistentry> | |
153 | <term>options <replaceable>modulename</replaceable> <replaceable>option...</replaceable> | |
154 | </term> | |
155 | <listitem> | |
156 | <para> | |
157 | This command allows you to add options to the module | |
158 | <replaceable>modulename</replaceable> (which might be an | |
159 | alias) every time it is inserted into the kernel: whether | |
445e51c5 JL |
160 | directly (using <command>modprobe </command> |
161 | <replaceable>modulename</replaceable>) or because the | |
5173e8e8 LDM |
162 | module being inserted depends on this module. |
163 | </para> | |
164 | <para> | |
165 | All options are added together: they can come from an | |
166 | <command>option</command> for the module itself, for an | |
167 | alias, and on the command line. | |
168 | </para> | |
169 | </listitem> | |
170 | </varlistentry> | |
171 | <varlistentry> | |
172 | <term>remove <replaceable>modulename</replaceable> <replaceable>command...</replaceable> | |
173 | </term> | |
174 | <listitem> | |
175 | <para> | |
176 | This is similar to the <command>install</command> command | |
177 | above, except it is invoked when "modprobe -r" is run. | |
178 | </para> | |
179 | </listitem> | |
180 | </varlistentry> | |
181 | <varlistentry> | |
182 | <term>softdep <replaceable>modulename</replaceable> pre: <replaceable>modules...</replaceable> post: <replaceable>modules...</replaceable> | |
183 | </term> | |
184 | <listitem> | |
185 | <para> | |
186 | The <command>softdep</command> command allows you to specify soft, | |
187 | or optional, module dependencies. <replaceable>modulename</replaceable> | |
188 | can be used without these optional modules installed, but usually with | |
189 | some features missing. For example, a driver for a storage HBA might | |
190 | require another module be loaded in order to use management features. | |
191 | </para> | |
192 | <para> | |
193 | pre-deps and post-deps modules are lists of names and/or aliases of other | |
194 | modules that modprobe will attempt to install (or remove) in order | |
195 | before and after the main module given in the | |
196 | <replaceable>modulename</replaceable> argument. | |
197 | </para> | |
198 | <para> | |
199 | Example: Assume "softdep c pre: a b post: d e" is provided in the | |
200 | configuration. Running "modprobe c" is now equivalent to | |
201 | "modprobe a b c d e" without the softdep. | |
202 | Flags such as --use-blacklist are applied to all the specified | |
203 | modules, while module parameters only apply to module c. | |
204 | </para> | |
205 | <para> | |
206 | Note: if there are <command>install</command> or | |
207 | <command>remove</command> commands with the same | |
208 | <replaceable>modulename</replaceable> argument, | |
209 | <command>softdep</command> takes precedence. | |
210 | </para> | |
211 | </listitem> | |
212 | </varlistentry> | |
213 | </variablelist> | |
214 | </refsect1> | |
215 | <refsect1><title>COMPATIBILITY</title> | |
216 | <para> | |
217 | A future version of kmod will come with a strong warning to avoid use of | |
218 | the <command>install</command> as explained above. This will happen once | |
219 | support for soft dependencies in the kernel is complete. That support | |
220 | will complement the existing softdep support within this utility by | |
221 | providing such dependencies directly within the modules. | |
222 | </para> | |
223 | </refsect1> | |
224 | <refsect1><title>COPYRIGHT</title> | |
225 | <para> | |
226 | This manual page originally Copyright 2004, Rusty Russell, IBM | |
227 | Corporation. Maintained by Jon Masters and others. | |
228 | </para> | |
229 | </refsect1> | |
230 | <refsect1><title>SEE ALSO</title> | |
231 | <para><citerefentry> | |
232 | <refentrytitle>modprobe</refentrytitle><manvolnum>8</manvolnum> | |
233 | </citerefentry>, | |
234 | <citerefentry> | |
235 | <refentrytitle>modules.dep</refentrytitle><manvolnum>5</manvolnum> | |
236 | </citerefentry> | |
237 | </para> | |
238 | </refsect1> | |
239 | </refentry> |