Re: modules.conf vs conf.modules
Kent West <westk@acu.edu> writes:
KW> Is there a plain-english ("for dummies") page somewhere that
KW> explains how modules work (modutils vs /etc/modules vs kmod vs
KW> kerneld vs conf.modules vs modules.conf vs /etc/modutils/ vs auto
KW> vs specific items in /etc/modules vs compile-in vs Godzilla vs
KW> Buck Rogers in the 23rd Century)?
I'll give this a shot. The Linux kernel arbitrates access to various
hardware devices, and provides (in theory, at least) consistent
interfaces to user-space programs. This means that there are various
hardware and protocol drivers that need to somehow be "part of the
kernel". There are two main ways to do this: compile the driver into
the kernel directly or load it at runtime as a kernel extension
module.[1]
Modules can actually get loaded in a couple of different ways. A
program called insmod actually does the loading. Another program,
called modprobe, is generally used to do the task, though. modprobe
reads /etc/conf.modules or /etc/modules.conf (either will work), and
uses the options there to determine proper module dependencies and
options. (So if module foo depends on bar, 'modprobe foo' will load
both foo and bar.)
Sometimes it's possible for a module to get automatically loaded. If
you try to, for example, access a device for which no kernel driver is
loaded, the kernel will attempt to load an appropriate module. On
Linux 2.0, this was done via an external program called kerneld. The
equivalent facility in 2.2 kernels is built into the kernel, and it's
called kmod. (So kmod and kerneld do exactly the same thing, but
which one you use is a function of which kernel you have. Debian
magically Does The Right Thing (TM) to start kerneld if necessary.)
/etc/modules determines which modules are loaded at boot-time on
Debian systems. Any module name listed there is loaded with
modprobe. If the keyword 'auto' is there, kerneld is immediately
loaded, if necessary; the keyword 'noauto' causes kerneld to never be
loaded. Otherwise, kerneld is loaded after much of the boot sequence
(IIRC).
As I mentioned a couple of paragraphs ago, /etc/conf.modules tells
modprobe what module dependencies, options, etc. should exist. On
current Debian systems, this is managed through the files in
/etc/modutils. A program called update-modules essentially cats
together all of the files under this directory. This setup gives
Debian a little more flexibility: if a particular package is
responsible for some set of module settings, it can update a file in
/etc/modutils and run update-modules, without tromping on other
packages' settings.
How is this relevant to a system administrator? Files you care about
are probably:
/etc/modules: lists modules to be loaded at boot time
/etc/modutils/*: fragments to be combined into a complete
/etc/conf.modules file; you can create, for example,
/etc/modutils/sound on your system with appropriate options for your
particular system's sound setup. Run update-modules after you
change anything here.
HTH...
[1] This means that it's theoretically possible to ignore this entire
modules nonsense and build everything you want into the kernel.
This is less flexible, though, and you need to rebuild the kernel
if you ever want to change things; it's a pain. Also, some
packages (e.g. ALSA) are only available as modules for the moment.
--
David Maze dmaze@mit.edu http://www.mit.edu/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: