Here is my current understanding of why one would choose to use one vs the other, can you please confirm or correct me?

  • Run-time vs compile-time: If you don't know whether or not you want this enabled until run time, use tristate. Else, you know at compile time, so use bool. In the cases where you #ifdef some optional code A inside some surrounding code B (for example including bonus features like GPU support or something) then you would need to make A be bool, even if the entire module B could be declared as tristate, since the ifdef is evaluated at compile.
  • Iteration speed: If you are developing a new bit of code, then if you declare it as a module then you can quickly unload the old version and reload your newly compiled version, without having to reboot the entire system.
  • Intrusiveness: Some code would be so disruptive to to dynamically add to an already running kernel (e.g. Symmetric-Multi-Processing), so it is always bool.

Are there other factors I'm missing here? Factors I could see myself missing could be

  • Performance
  • Security
  • Rules of Thumb (e.g. "Always use bool unless you need to use tristate")

Other explanations, notes, links, and thoughts would be greatly appreciated. Thanks!

  • 1
    I think you are looking at this too much from the kernel module writers perspective. There is variance in the wishes of the consumers of your kernel module. For example, somebody putting together a Linux distribution would want to support a range of hardware devices that is as wide as possible, but would not want to ship a gigakernel with every driver built in. On the other hand, somebody who is configuring the kernel for some specific device would perhaps prefer to build a kernel with just the needed features built in, maybe because that's simplest and most convenient for him or her. – Johan Myréen Mar 5 at 20:05
  • @JohanMyréen, thanks, that's a great point. I guess I still don't understand though, why would someone putting together a distro prefer tristate or bool? They would prefer bool if they are sure the feature is or is not necessary for the user, and module if a user of the distro maybe wants the feature? – Nick Crews Mar 8 at 20:50
  • 1
    Tristate is better because it gives more choice to the person configuring and compiling the kernel: he or she can choose between compiling the feature directly into the kernel, or as a separate module, or disabling the feature. You would never prefer bool, because it gives you less choices, but, as has been pointed out in the answer below, it isn't always possible to provide features as loadable modules. A distro wants to provide as much as possible as loadable modules, since somebody putting together a distro does not know what the end user wants. – Johan Myréen Mar 9 at 18:22
  • Thanks, this makes sense and is what I was looking for. – Nick Crews Mar 11 at 19:09

Citation from https://www.linuxjournal.com/content/kbuild-linux-kernel-build-system

Not everything in the kernel can be compiled as a module.

Many features are so intrusive that you have to decide at compilation time whether the kernel will support them. For example, you can't add Symmetric Multi-Processing (SMP) or kernel preemption support to a running kernel. So, using a boolean config symbol makes sense for those kinds of features.

Most features that can be compiled as modules also can be added to a kernel at compile time. That's the reason tristate symbols exist—to decide whether you want to compile a feature built-in (y), as a module (m) or not at all (n).

I think this is clear: If there are only two choices, use a boolean, if there are three choices use tristate. Everything else would not make sense.

  • Sure, those are rules for what is possible (I even cited this indirectly, I should have actually linked it), but I was asking why you would choose one vs the other given the choice – Nick Crews Mar 8 at 20:46
  • 1
    I don't see any other reason not to use tristate over boolean than the reason mentioned above. Some features simply don't make sense or are too hard to provide as loadable modules. Tristate is a superset of boolean; there is no advantage in providing only boolean if tristate is possible. – Johan Myréen Mar 9 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.