# etc/conf.d/modules with built-in kmods

## hack.canada

New Gentoo user here  :Smile: 

I have a questions regarded the configuration of kernel modules at start-up.  Specifically in the handbook, I am referring to the section at the base of the kernel configuration page here: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Configuring_the_modules

After configuring and compiling your kernel, the guide directs you to list all of the modules that need to be loaded "automatically" in the etc/conf.d/modules file.  This seems pretty self-explanatory to me as one's kernel would need to know how to interact with vital hardware and systems upon booting (i.e. how to even know what an ext3 filesystem IS) 

HOWEVER...

Wasn't the point (if you chose to do so) of building certain, vital modules INTO the kernel that they would not need to be loaded in manually, either by issuing modprobe commands at the terminal or via a startup script?  The reason I am asking to clarify is that the Handbook itself jumps straight into this section after compiling your kernel, but does not give any information pointing to situations where it would NOT be necessary to add entries to the modules file.  i.e. I didn't want to get to the point of rebooting into the new environment and have my kernel not able to recognize anything if I left the modules file blank, going on my assumption that "built-in" or compiled in modules would simple be loaded no matter what.

Also, as an aside and simply because it piqued my general curiousity, maybe someone can enlighten me as to the meaning of "firmware" in a strict sense as it relates to modules and the kernel... if one's kernel needs a module present and loaded in order to recognize, understand, and interact with specific types of hardware, then why would some modules also need "firmware"?  I mean, before I had read that I was under the impression that the modules WERE the lower level translation for the kernel -> hardware and thus -> user ?  So if a certain piece of hardware, let's say a wireless NIC, needs a kernel module loaded as well as firmware, why on earth would the module not just "bundle" in the firmware contents?  Clearly I'm missing the point somewhere here, but I am really interested in learning more about what is REALLY going on here.

If my description is unclear, please let me know and I would be happy to provide any clarification  :Smile:  ...sometimes I ramble on...

Thanks!

----------

## DawgG

everything the kernel does not detect "automagically" and you want to use with a module needs to be listed in /etc/conf.d/modules. hardware is ususally detected correctly and the right module is loaded automagically by the kernel (if the module exists).

the main point of building certain features "into" the kernel is that certain features are supported before the root-fs that stores the modules becomes available (and you don't need/want an initrd); eg for a raid-controller.

i ususally compile erverything needed to run the system into the kernel (hardware, filesystems, networking-features) and optional stuff (eg. usb-wifi-drivers) as modules.

if your kernel is able to mount and access the root-fs (where your modules are stored) either by compiling everything "into" it or by using an initrd there is a big chance you do not need to list anything in /etc/conf.d/modules except for special cases (eg modules for virtualization-software, fuse, ...)

when i am not certain about the exact type or revision of (non-vital) hardware (eg sensors) i ususally compile a couple of modules that seem closest and then let the kernel load the correct one (it's not guaranteed but usually works).

here's the list of modules loaded on a box like that (/etc/conf.d/modules empty):

```
grunt ~ # lsmod

Module                  Size  Used by

(...)

coretemp                4542  0

drm                   248385  4 ttm,drm_kms_helper,mgag200

hwmon                   2738  1 coretemp

x86_pkg_temp_thermal     3048  0

lpc_ich                14040  0

crc32_pclmul            2603  0

mfd_core                3313  1 lpc_ich

hed                     1546  0

acpi_pad                4295  0
```

firmware is a binary file needed by hardware to be (fully) supported. some hardware-companies do not let programmers write GPL- or "open source" code (drivers) for every part or function of their components but hide that in a binary firmware-file (that is loaded like a kind of "black box"). some firmware can be loaded automagically and some has to be compiled into the kernel.

----------

## Logicien

Hello,

the kernel have an option to autoload modules. It do it pretty well and after the boot process not a lot of modules need to be add by the administrator to /etc/conf.d/modules or load by an other mean.

When a module is already loaded and is ask to be loaded again without having being unloaded before, the Linux kernel just ignore the request with a 0 exit. So it is not a problem if the kernel load a module and a boot script try to load it again. The essential is that each needed modules are load successfully and at the appropriate moment.

If you want to be sure that no module is load twice, just boot without any module to load in /etc/conf.d/modules and than modprobe the ones you want that the kernel haven't load. You may realise that there is a reason why a module is not load. If not add it to /etc/conf.d/modules .

If you want to change a parameter of a module who is already load, you need to unload it (if possible) and load it again with the new parameter at the command line or from /etc/modprobe.d/*.conf .

One reason I think who explain why the firmware files are not include in the module or in the kernel image automatically is the non free licences of some firmware files. If you want to taint the kernel, you have to do it by yourself.

I put only what is essential to boot successfully in the kernel image and all the rest in modules. The practice have show me that some none essential supports can be better in the kernel image anyway. It depend of the kernel messages.

An advantage of modules is that they are often unloadable and loadable again. You can change the parameter of a module without have to reboot and you can use /etc/modprobe.d/ directory to set parameters instead of the kernel option for this and the bootloader command line.

The directory /etc/modprobe.d/ need to be include in an initramfs when you use one as well than everything essential to boot successfully that the kernel image do not have. With Gentoo, I use an initramfs mostly to have an early Fbcondecor splash image and for firmware files that the kernel complain that are not available in time, for nouveau, i915 and microcode as example.

With the appropriate setup, tools to create an initramfs like Dracut include a module dependancies and the firmware files they all need when you explicitely ask this module to be added to the initramfs. Of course what Dracut need to add in the initramfs must be present in the system.

What I follow is when a support need firmware files I add those files at the same level than the support is, in the kernel image or in an initramfs and, always in the root filesystem.

It is important that the firmware files are available when the support probe the hardware because otherwise, the support may fail to dialog with the device even if the firmware files are availlable later in the boot process.

----------

## Fitzcarraldo

 *hack.canada wrote:*   

> Wasn't the point (if you chose to do so) of building certain, vital modules INTO the kernel that they would not need to be loaded in manually, either by issuing modprobe commands at the terminal or via a startup script?

 

Perhaps I'm misunderstanding your question, but I think you are alluding to the distinction between -- to give a random example -- the following kernel configuration:

```
<M>   MMC block device driver
```

and the following kernel configuration:

```
<*>   MMC block device driver
```

In the former case, the kernel configuration file would contain:

```
CONFIG_MMC_BLOCK=m
```

and in the latter case, the kernel configuration file would contain:

```
CONFIG_MMC_BLOCK=y
```

If you specified '<*>' (i.e. you built the driver into the kernel rather than building the driver as a module) then you certainly do not need to add anything to the /etc/conf.d/modules file, because you did not build the driver as a module, you built it directly into the kernel. However, if you specified '<M>' (i.e. you built the driver as a module -- a separate file with the suffix '.ko' -- rather than building it into the kernel) then you may have to declare it in /etc/conf.d/modules file to get it to load automatically. I'm no expert in the process, but udev loads some modules (if you built the drivers as modules) automatically without you needing to declare them in the /etc/conf.d/modules file, and the kernel loads some modules (if you built the drivers as modules) automatically without you needing to declare them in the /etc/conf.d/modules file. In some cases, udev or the kernel are not able to load drivers that have been built as modules, in which case you will have to declare them in the /etc/conf.d/modules file. I had this problem with the memory card slot in one of my laptops, which is actually a USB device. I built the driver as a module -- by specifying '<M>' when configuring the kernel -- but that specific driver was not loaded automatically at boot, so I declared it in the /etc/conf.d/modules file. You will find that the kernel and udev are able to load most modules automatically without the need to declare them in /etc/conf.d/modules. The current wording in the section in the Gentoo Handbook to which you referred is rather confusing in my opinion; it could be interpreted to mean that no modules are loaded automatically unless they are declared in the file /etc/conf.d/modules, so I can understand your confusion.

For further reading, see, e.g., Udev: Introduction to Device Management In Modern Linux System and How does the Linux kernel know which drivers to load at boot? [closed].

----------

## krinn

 *DawgG wrote:*   

> hardware is ususally detected correctly and the right module is loaded automagically by the kernel (if the module exists).

 It just never do that.

The hardware detection and module loading for it is done by device manager, as people use mostly (e)udev it do that ; but with a dev manager that doesn't ; you won't get any result (some use static dev or whatever dev manager they like).

hack.canada:

Think about it: kernel is waiting to load your rootfs, so basically kernel just boot and load every build-in drivers you have set, waiting to be able to discover your rootfs to load it. Once drivers for your controller are loaded, and devices enumerated, if kernel see and can use your root device, it mount it.

It is only at this point when root is mount, that modules are accessible ; before that, you just cannot see or access any. 

That's why you cannot use a driver build as module for your controller or you need initram, a chicken/egg problem: kernel cannot see modules if rootfs is not mount, kernel cannot use rootfs if the modules for it are not loaded.

So basically, there's just never any critical modules in /etc/conf.d/modules file. If you can boot, you can modprobe what you need ; if you cannot boot, even adding them to the file won't let you boot.

You may argue, that booting with a network card is critical, when in real, booting successfully is critical, as once you succeed you can load that network card driver that is vital in your eyes, but for kernel it just don't care about it.

You could just see /etc/conf.d/modules as an anti-boring file, if you get bored to modprobe something after your kernel is loaded, add it to that file.

----------

