3

Suppose I set a tristate kernel configuration option to be built as a module, but I don't load the corresponding kernel module at runtime (and it doesn't get loaded automatically). Is the functionality of the resulting kernel equivalent to what it would be if I had disabled the option outright? Or is there some difference between an unloaded module and a disabled kernel option?

Sometimes when installing packages on my Gentoo system, I get warnings of the form

CONFIG_FLUX_CAPACITOR is set when it should not be

Typically it turns out that the option is actually set to be built as a module which is then not loaded. The software seems to work fine in each case I've encountered so far, but I'm wondering if this is something I can expect to be okay in general.

1
  • I've found this to be indicative of behavior the developer expects out of his program for the behavior all the major distributions see. As Gentoo users, we get that opportunity or more. If the FLUX_CAPACITOR option is a base kernel option (can only be set to *) then setting it is usually recommended, otherwise the ebuild wouldn't complain. If the FLUX_CAPACITOR can be set as a module, and was built as a module, setting it via modules.autoload.d is acceptable, and again the ebuild wouldn't complain.
    – eyoung100
    Jul 18, 2015 at 19:53

1 Answer 1

2

Disabled compile time option means the code isn't compiled.

Unloading a module means, that the code has been compiled into a module, but is not loaded in memory and thus is not run. Be aware, that sometimes the modules may be loaded automatically, so if you need to disable certain functionality, the safe option is to disable it at compile time or blacklisting it in /etc/modprobe.conf or /etc/modprobe.d/*. Or removing the module file from the filesystem - you might want to run depmod afterwards and make a mental note, that there might be some other modules that depend on it (which might cause some troubles later on).

That said, capability wise it is the same. There may (or may not) be a slight difference in the code that is adapted to be running with or without the module you are (not) disabling: suppose you can compile kernel with feature A as a module. If feature B is capable of using feature A but doesn't require it, the resulting code might be different. With A enabled (regardless of that being as a module or compiled in), B may include an optional check for the presence of feature A. With A disabled at compile time, such check in B is irrelevant and may be skipped completely. This however is something that has to explicitly stated in the code itself (e.g. via a C #ifdef directive), the compiler alone can't decide that. Hence it depends on the authors of the parts that have feature A as optional dependency. Whether it should be called functionally different is questionable - it doesn't alter the capabilities but very likely changes execution time (even though just a little - yet even that might be crusial in some corner cases).

4
  • Thanks, but I actually knew that much already. I'm really asking whether there are any differences between these two options, with respect to the running kernel.
    – David Z
    Jul 18, 2015 at 10:50
  • Sorry, replying in a hurry resulted in a bit uncooked answer. It should be a bit better now.
    – peterph
    Jul 18, 2015 at 13:58
  • Yeah, that last paragraph is more what I'm getting at. My concern is more about code compatibility than speed or responsiveness, but I didn't really expect any guarantees on that. I'll wait a little while to see if anyone else answers and then come back to this.
    – David Z
    Jul 18, 2015 at 14:17
  • Compatibility wise it should be the same, although no-one can guarantee, that disabling A won't cripple B, because the author might just have messed up somewhere. It's likely it won't happen due to the review process, though.
    – peterph
    Jul 18, 2015 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .