[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: modules.conf vs conf.modules

"David Z. Maze" wrote:
> 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

This was good. Thank you!

Reply to: