Modules loaded in FreeBSD 13

Generic 13 loads a bunch of modules and I can't figure out why or what is loading them. They're not defined in the default loader.conf; What is controlling the loading of these modules?

Code:
 kldstat


Id Refs Address                Size Name


 3    1 0xffffffff82320000     3378 acpi_wmi.ko
 4    1 0xffffffff82324000     3250 ichsmb.ko
 5    1 0xffffffff82328000     2180 smbus.ko
 6    1 0xffffffff8232b000     8d38 ioat.ko
 7    1 0xffffffff82334000     2340 uhid.ko
 8    1 0xffffffff82337000     4350 ums.ko
 9    1 0xffffffff8233c000     3380 usbhid.ko
10    1 0xffffffff82340000     31f8 hidbus.ko
 
Good question.
These modules are part of the kernel. And when the kernel detects them it loads them.
There is in general no reason to blacklist modules.
 
One can do something like "man ums" and get a bit of information about a module. Roughly the kernel is enumerating system hardward, detects the need for the module and loads it. Some of the loading comes from devfs/devd, some comes from loader.conf, some comes from the kernel itself.

In "days of yore" you would have statements in kernel configurationt that would build them in, but over time the GENERIC kernel config has less actually built in and more and more modules. Why? Overall more generic, able to boot on more machines, means a user doesn't need to rebuild a kernel for their machine.

So "man acpi_wmi", "man ichsmb", "man smbus" etc to find out what they do for you.

As Alain De Vos says, don't blacklist them.
 
OP, I deeply apologize for not being more explicit in providing exactly what you are looking for in an answer. I implied quite a bit of stuff. I will attempt to provide more information; if I fail, please accept my apologies in advance.

This is a rough outline of my understanding, a kernel guru may have quibbles with exact verbiage used, but I believe it is roughly correct.

/boot/modules and /boot/kernel contain all the loadable modules that can be inserted into a running system.
When the kernel starts, it has routines that probe hardware; you can look at the output of dmesg to get a feel for that.
In order for a bit of hardware to be usable, it needs to have a device driver attached.
Two ways of getting that device driver attached:
Compile everything into the kernel
Have loadable modules and a "hints" file that causes things to get loaded.

/boot/kernel/linker.hints and /boot/modules/linker.hints are hints files.

Kernel boots, starts probe, sees something that looks like an USB device, it looks to see if it's compiled in, if not, looks at linker.hints to see if there is anything it knows about to service the device. If so, it loads the module. Now you have a module loaded and a device driver attached so the device can be used.

You can also explicitly load modules in loader.conf or by the kldlist in /etc/rc.conf. Don't forget about /etc/defaults/rc.conf: there may be explicit loads in there. The DRM video drivers are a common use of this.

You can also load modules via the devd/devfs/devmatch system: plug in an USB mouse, top level USB subsystem detects it, base on standard USB config items, determines that it is a mouse, checks to see if there is a mouse driver loaded, if so it attaches the device to that driver, if not, loads what it needs to like ums.ko, and attaches to that.

Loading of a module may trigger loading of other modules it needs: ums may cause uhid to get loaded.

Hopefully this is answer is closer to what you wanted; if not, again I apologize and feel free to ignore it.
 

The culprit is in /etc/defaults/rc.conf:

devmatch="YES"

turning this off and the unwanted modules don't load. HOWEVER, my FreeBSD 12 disk also has devmatch set and it doesnt load the modules on the same hardware. So it's some new mysterious feature.
 
OP, I deeply apologize for not being more explicit in providing exactly what you are looking for in an answer. I implied quite a bit of stuff. I will attempt to provide more information; if I fail, please accept my apologies in advance.

This is a rough outline of my understanding, a kernel guru may have quibbles with exact verbiage used, but I believe it is roughly correct.

/boot/modules and /boot/kernel contain all the loadable modules that can be inserted into a running system.
When the kernel starts, it has routines that probe hardware; you can look at the output of dmesg to get a feel for that.
In order for a bit of hardware to be usable, it needs to have a device driver attached.
Two ways of getting that device driver attached:
Compile everything into the kernel
Have loadable modules and a "hints" file that causes things to get loaded.

/boot/kernel/linker.hints and /boot/modules/linker.hints are hints files.

Kernel boots, starts probe, sees something that looks like an USB device, it looks to see if it's compiled in, if not, looks at linker.hints to see if there is anything it knows about to service the device. If so, it loads the module. Now you have a module loaded and a device driver attached so the device can be used.

You can also explicitly load modules in loader.conf or by the kldlist in /etc/rc.conf. Don't forget about /etc/defaults/rc.conf: there may be explicit loads in there. The DRM video drivers are a common use of this.

You can also load modules via the devd/devfs/devmatch system: plug in an USB mouse, top level USB subsystem detects it, base on standard USB config items, determines that it is a mouse, checks to see if there is a mouse driver loaded, if so it attaches the device to that driver, if not, loads what it needs to like ums.ko, and attaches to that.

Loading of a module may trigger loading of other modules it needs: ums may cause uhid to get loaded.

Hopefully this is answer is closer to what you wanted; if not, again I apologize and feel free to ignore it.
I appreciate your effort but I've been building module free BSD kernels since BSDI was in beta. So there's something very different in 13.

Your assertion that keeping unwanted, unneeded modules from loading on the system is "blacklisting" was too absurd to respond to.
 
To follow up on this, I have my 12 system built with NO_MODULES=yes so it's possible they're not loading because they're not available to load :)
 
I have modules ums.ko and smbus.ko loaded but they are not listed in the GENERIC configuration file of the KERNEL ...
Nor does there exist something for it in src.conf ...
So the setting is in make.conf. Where an immediate question arises.
Where is the list of all the modules for your kernel you can list in "WITHOUT_MODULES" ?
 
I have modules ums.ko and smbus.ko loaded but they are not listed in the GENERIC configuration file of the KERNEL ...
Nor does there exist something for it in src.conf ...
So the setting is in make.conf. Where an immediate question arises.
Where is the list of all the modules for your kernel you can list in "WITHOUT_MODULES" ?
how about

ls -l /boot/kernel/*.ko

All modules are built by default. There are a million of them that you'll never need; I suggest using MODULES_OVERRIDE to just list the ones you want rather than all the ones you don't want. You don't want a lot more than you do.
 
my rc.conf
Code:
kld_list="drm radeonkms snd_driver cc_cubic \
cpuctl coretemp hwpmc ichsmb ipmi drm sem smbus \
usb_template ums ulpt umodem uslcom ucom nmdm iic ow \
fusefs udf \
uhid ums \
libiconv libmchain cd9660_iconv msdosfs_iconv "
It's not like they hurt.
When I have time I try to find out the ones which are needless.
 
I dont get why anyone would want so many modules instead of a custom kernel with the stuff you want. But we all live in different universes.
 
Back
Top