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: