Talk:Kernel Modules

Remove section "Going completely 'module-less'" ?

Talk status

This discussion is done as of 2021-12-15.

This seems - prima facie - almost a little silly, but I know little about this. Are there situations this could be useful for (embedded comes to mind) ? I'm worried this might be a "ricer thing", in which case it wouldn't helping anyone to mention it...

-- Kyoreln (talk) 20:37, 12 November 2021 (UTC)

I'm the author that added the section several years ago. I think one needs to understand why the Linux kernel has loadable module support in the first place. Unlike some operating system kernels, in Linux all of the device drivers are part of the kernel. There are a lot of different devices out there, but any given machine needs drivers for only a tiny subset of all available devices. That becomes a big problem for distributions, if all the modules are loaded in a monolithic kernel image at all times. Thus loadable modules were introduced. It allows a distribution, like Fedora or Ubuntu, to provide a binary kernel package that contains all the drivers for the whole universe of hardware out there. On any given machine, only a subset of those drivers can be loaded. Problem solved.

But Gentoo is a distribution that doesn't have this problem (at least not for users building their own kernel, which is probably the vast majority of Gentoo users). The kernel configuration most often only enables those drivers that the Gentoo user knows they need on their machine. Those drivers can simply be built into the kernel. There is no reason why the Gentoo user needs to select "M" for any driver when configuring the kernel (unlike the distribution kernel maintainers that must select "M" for most drivers).

For the Gentoo user that configures their own kernel, if they build-in all of their device drivers (and all other kernel options they know they always want available), it makes sense to just dispense with loadable module support altogether. In a lot of cases, loadable module support will be enabled, even though no loadable modules are even built.

As for whether this section should be in the Wiki, I only have this to say: when I added this there was scant help anywhere else on how to do it. Since the Wiki is here to help users with system configuration so they don't have to figure out everything on their own, it seems appropriate to keep it. It doesn't harm anyone to make this information available. But removing this section would remove the possibly only source on the web that has instructions how to configure Gentoo for a system that doesn't need loadable modules.

-- Dmoulding (talk) 23:15, 13 November 2021 (UTC)

Wow, thanks for the detailed - and rapid - answer!!

Sorry for suggesting that this might be "silly", I really don't know much about this at all, I just worry about anything that might lead novice users down a "slippery path". The warning that is already there is surely quite sufficient then.

Agreed that making current information available can only help (with a warning when appropriate). Thanks again for the complete answer, anybody coming here having questions about this will benefit! :).

-- Kyoreln (talk) 00:07, 14 November 2021 (UTC)

Loading modules during boot

Talk status

This discussion is done.

It looks like the current subsection is inaccurate. /etc/modules-load.d is a directory that systemd-modules-load.service(8) reads from. It isn't stated that this directory is specific for systemd installations, and OpenRC alternative is not mentioned. I believe the alternative is /etc/conf.d/modules.

Can someone please confirm this? I've installed Gentoo just yesterday and don't know if this is true.

-- Tlaguz (talk) 22:46, 9 January 2022 (UTC)

I use /etc/modules-load.d/ with OpenRC. Seems that both paths you mentionned should work[1]. -- Ris (talk) 08:31, 10 January 2022 (UTC)

Once systemd integration became popular, OpenRC included a new script for reading modules-load.d. Later this was integrated directly into /etc/init.d/modules so that /etc/modules-load.d is easily used in both systems. It is much easier to describe it once for all then duplicate the OpenRC unique method. OpenRC will work with both just fine even if the older conf.d file adds version specifics (but I've rarely seen a use case for it). --Grknight (talk) 14:37, 10 January 2022 (UTC)

Thank you for the explanation! What about adding the following sentence: "This method is supported by both systemd and OpenRC (since version 0.21.7)" to clarify things? I'm asking here since I saw that there is no review of changes. Source: https://abi-laboratory.pro/index.php?view=changelog&l=openrc&v=0.21.7 commit b888f1a8e21008f45105ad2fdc84a5d579892eb5 -- Tlaguz (talk) 13:45, 27 January 2022 (UTC)

This is a bit pointless at this juncture. The support has existed for five years already. Anyone with that ancient of an install isn't likely to make modern changes. https://github.com/OpenRC/openrc/tags?after=0.22.2 --Grknight (talk) 14:01, 27 January 2022 (UTC)

You are right, pointing the version is pointless. But I still think that information about OpenRC support should be noted. I thought that this method works only on systemd because on an OpenRC install said directory is missing, there is no manpage for modules-load.d, and on any other distro with systemd there is a manpage in which description starts with: "systemd-modules-load.service(8) ...". So in this circumstances I thought that there must be a different way, specific for OpenRC. -- Tlaguz (talk) 14:31, 27 January 2022 (UTC)

Added one small sentence but you could have as well. The path missing argument is not a real issue as many paths do not exist until you need them. When a Gentoo document refers to it, often an admin needs to create the said path. Most good programs just skip over non-exist paths when not critical. --Grknight (talk) 14:46, 27 January 2022 (UTC)