MODULES_OVERRIDE - Does it define only dynamic modules?

[blazingice]

Due to a previous issue described here I had to delve for the first time into building/installing a new kernel. As I understand it, there are three ways to define how modules are being built. The most prescriptive option is MODULES_OVERRIDE, which allows one to define exactly the number of modules that will be built during make buildkernel. This is set in make.conf. Here is an example that I have been testing:

MODULES_OVERRIDE=             
                                zfs \
                                cryptodev \
                                i2c/controllers/ichsmb \
                                i2c/controllers/intpm \
                                i2c/smbus \
                                usb/uhid \
                                usb/ums \
                                usb/usbhid \
                                hid/hidbus \
                                usb/wmt \
                                filemon

My question is whether this list is meant to reflect only dynamic modules that can be loaded via loader.conf or kldload, or should it also include modules that are linked statically to whatever is set in MYKERNEL config file?

For example if MYKERNEL includes:

device        em            # Intel PRO/1000 Gigabit Ethernet Family

Will I need to include em also in the above MODULES_OVERRIDE list?

 

[zirias@]

modules that are linked

The very short answer: No such thing exists, by definition, something linked statically is not a module.

When you're already fiddling with a list of modules to build (instead of building just all of them), you probably don't want to list drivers there that you already include in the kernel. FreeBSD's kernel build system is pretty simple, it just builds all possible modules by default. It doesn't matter whether some (driver) code is already built into the kernel, if this code can go into a module, the module will be built unless you disable that.

 

[Andriy]

The very short answer: No such thing exists, by definition, something linked statically is not a module.

Technically, you are incorrect.

What everyone causally calls a kernel module is a kernel loadable file (that's where "kld" prefix comes from).
A kernel loadable file can contain multiple modules.
And the kernel also contains multiple modules, e.g., for drivers that are statically compiled in.
If you run kldstat -v you can see "real" modules in kernel loadable files and the kernel itself.

Also, see module(9).

 

[zirias@]

Technically, you are incorrect.

Excuse me, but I'd say that context matters a lot here ...

We were in the context of "build artifacts", and "module" in that context means, well, the "kernel object" file (to use a different word, because "kernel loadable file" also sounds quite constructed ....) that's separate from the kernel itself.

What everyone causally calls a kernel module is a kernel loadable file (that's where "kld" prefix comes from).

I'd rather assume "kld" refers to "kernel link dynamic" or something like this.

A kernel loadable file can contain multiple modules.
And the kernel also contains multiple modules, e.g., for drivers that are statically compiled in.
If you run kldstat -v you can see "real" modules in kernel loadable files and the kernel itself.

Also, see module(9).

That's the context of the inner architecture of the kernel. (where "modules" are a common concept for clear boundaries within a complex system)

Yep, using the same word for different things isn't ideal. IMHO, if you wanted to resolve this, it would make sense to refer to "kernel objects" instead (that's where .ko comes from), but I'd very much doubt you could ever establish a new wording "in the wild"....

 

[blazingice]

Thanks both. Your explanations are very helpful. Basically the process of building the kernel and the process of building modules are not interconnected, although they are activated by make buildkernel. Whatever gets compiled in the kernel is informed by MYKERNEL config file, which can include devices,etc. Whereas all dynamic modules are built 'separately', and can be defined by MODULES_OVERRIDE irrespective of MYKERNEL config file.

For some reason I was expecting these two processes to inform each other, hence the question. All clear now!