| .\\" auto-generated by docbook2man-spec $Revision: 1.2 $ |
| .TH "MODPROBE.CONF" "5" "2010-03-09" "" "" |
| .SH NAME |
| modprobe.d, modprobe.conf \- Configuration directory/file for modprobe |
| .SH "DESCRIPTION" |
| .PP |
| Because the \fBmodprobe\fR command can add or |
| remove more than one module, due to modules having dependencies, |
| we need a method of specifying what options are to be used with |
| those modules. All files underneath the |
| \fI/etc/modprobe.d\fR directory which end with the |
| \fI\&.conf\fR extension specify those options as |
| required. (the \fI/etc/modprobe.conf\fR file can |
| also be used if it exists, but that will be removed in a future |
| version). They can also be used to create convenient aliases: |
| alternate names for a module, or they can override the normal |
| \fBmodprobe\fR behavior altogether for those with |
| special requirements (such as inserting more than one module). |
| .PP |
| Note that module and alias names (like other module names) can |
| have - or _ in them: both are interchangable throughout all the |
| module commands as underscore conversion happens automatically. |
| .PP |
| The format of and files under \fImodprobe.d\fR and |
| \fI/etc/modprobe.conf\fR is simple: one |
| command per line, with blank lines and lines starting with '#' |
| ignored (useful for adding comments). A '\\' at the end of a line |
| causes it to continue on the next line, which makes the file a |
| bit neater. |
| .SH "COMMANDS" |
| .TP |
| \fBalias \fIwildcard\fB \fImodulename\fB\fR |
| This allows you to give alternate names for a module. For |
| example: "alias my-mod really_long_modulename" |
| means you can use "modprobe my-mod" instead of "modprobe |
| really_long_modulename". You can also use shell-style |
| wildcards, so "alias my-mod* really_long_modulename" |
| means that "modprobe my-mod-something" has the same |
| effect. You can't have aliases to other aliases (that |
| way lies madness), but aliases can have options, which |
| will be added to any other options. |
| |
| Note that modules can also contain their own aliases, |
| which you can see using \fBmodinfo\fR\&. These |
| aliases are used as a last resort (ie. if there is no real |
| module, \fBinstall\fR, |
| \fBremove\fR, or \fBalias\fR |
| command in the configuration). |
| .TP |
| \fBblacklist \fImodulename\fB\fR |
| Modules can contain their own aliases: usually these are |
| aliases describing the devices they support, such as |
| "pci:123...". These "internal" aliases can be overridden |
| by normal "alias" keywords, but there are cases where two |
| or more modules both support the same devices, or a module |
| invalidly claims to support a devicei that it does not: the |
| \fBblacklist\fR keyword indicates that all of |
| that particular module's internal aliases are to be ignored. |
| .TP |
| \fBinstall \fImodulename\fB \fIcommand...\fB\fR |
| This command instructs \fBmodprobe\fR to run your |
| command instead of inserting the module in the kernel as normal. |
| The command can be any shell command: this allows you to do any |
| kind of complex processing you might wish. For example, if the |
| module "fred" works better with the module "barney" |
| already installed (but it doesn't depend on it, so |
| \fBmodprobe\fR won't automatically load it), |
| you could say "install fred /sbin/modprobe barney; |
| /sbin/modprobe --ignore-install fred", which would do what |
| you wanted. Note the \fB--ignore-install\fR, |
| which stops the second \fBmodprobe\fR from |
| running the same \fBinstall\fR command again. |
| See also \fBremove\fR below. |
| |
| The long term future of this command as a solution to the |
| problem of providing additional module dependencies is not assured |
| and it is intended to replace this command with a warning about |
| its eventual removal or deprecation at some point in a future |
| release. Its use complicates the automated determination of module |
| dependencies by distribution utilities, such as mkinitrd (because |
| these now need to somehow interpret what the |
| \fBinstall\fR commands might be doing. |
| In a perfect world, modules would provide all dependency |
| information without the use of this command and work is underway |
| to implement soft dependency support within the Linux kernel. |
| |
| If you use the string "$CMDLINE_OPTS" in the command, it |
| will be replaced by any options specified on the modprobe |
| command line. This can be useful because users expect |
| "modprobe fred opt=1" to pass the "opt=1" arg to the |
| module, even if there's an install command in the |
| configuration file. So our above example becomes "install |
| fred /sbin/modprobe barney; /sbin/modprobe |
| --ignore-install fred $CMDLINE_OPTS" |
| .TP |
| \fBoptions \fImodulename\fB \fIoption...\fB\fR |
| This command allows you to add options to the module |
| \fImodulename\fR (which might be an |
| alias) every time it is inserted into the kernel: whether |
| directly (using \fBmodprobe\fR |
| \fImodulename\fR or because the |
| module being inserted depends on this module. |
| |
| All options are added together: they can come from an |
| \fBoption\fR for the module itself, for an |
| alias, and on the command line. |
| .TP |
| \fBremove \fImodulename\fB \fIcommand...\fB\fR |
| This is similar to the \fBinstall\fR command |
| above, except it is invoked when "modprobe -r" is run. |
| .TP |
| \fBsoftdep \fImodulename\fB pre: \fImodules...\fB post: \fImodules...\fB\fR |
| The \fBsoftdep\fR command allows you to specify soft, |
| or optional, module dependencies. \fImodulename\fR |
| can be used without these optional modules installed, but usually with |
| some features missing. For example, a driver for a storage HBA might |
| require another module be loaded in order to use management features. |
| |
| pre-deps and post-deps modules are lists of names and/or aliases of other |
| modules that modprobe will attempt to install (or remove) in order |
| before and after the main module given in the |
| \fImodulename\fR argument. |
| |
| Example: Assume "softdep c pre: a b post: d e" is provided in the |
| configuration. Running "modprobe c" is now equivalent to |
| "modprobe a b c d e" without the softdep. |
| Flags such as --use-blacklist are applied to all the specified |
| modules, while module parameters only apply to module c. |
| |
| Note: if there are \fBinstall\fR or |
| \fBremove\fR commands with the same |
| \fImodulename\fR argument, |
| \fBsoftdep\fR takes precedence. |
| .SH "COMPATIBILITY" |
| .PP |
| A future version of module-init-tools will come with a strong warning |
| to avoid use of the \fBinstall\fR as explained above. This |
| will happen once support for soft dependencies in the kernel is complete. |
| That support will complement the existing softdep support within this |
| utility by providing such dependencies directly within the modules. |
| .SH "COPYRIGHT" |
| .PP |
| This manual page originally Copyright 2004, Rusty Russell, IBM |
| Corporation. Maintained by Jon Masters and others. |
| .SH "SEE ALSO" |
| .PP |
| \fBmodprobe\fR(8), |
| \fBmodules.dep\fR(5) |