Why use tristate vs bool in the Linux kernel Kconfig?

Clash Royale CLAN TAG#URR8PPP

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!

asked Mar 5 at 16:34

Nick Crews

1011

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

add a comment |

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!

asked Mar 5 at 16:34

Nick Crews

1011

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

add a comment |

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!

asked Mar 5 at 16:34

Nick Crews

1011

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!

linux kernel linux-kernel configuration

asked Mar 5 at 16:34

Nick Crews

1011

asked Mar 5 at 16:34

Nick Crews

1011

asked Mar 5 at 16:34

Nick Crews

1011

asked Mar 5 at 16:34

Nick Crews

1011

asked Mar 5 at 16:34

Nick Crews

1011

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

add a comment |

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

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

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

add a comment |

1 Answer
1

active

oldest

votes

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.

edited Mar 11 at 11:00

answered Mar 5 at 18:24

Bodo

2,271618

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

add a comment |

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504539%2fwhy-use-tristate-vs-bool-in-the-linux-kernel-kconfig%23new-answer', 'question_page');

);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

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.

edited Mar 11 at 11:00

answered Mar 5 at 18:24

Bodo

2,271618

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

add a comment |

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.

edited Mar 11 at 11:00

answered Mar 5 at 18:24

Bodo

2,271618

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

add a comment |

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.

edited Mar 11 at 11:00

answered Mar 5 at 18:24

Bodo

2,271618

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.

edited Mar 11 at 11:00

answered Mar 5 at 18:24

Bodo

2,271618

edited Mar 11 at 11:00

answered Mar 5 at 18:24

Bodo

2,271618

answered Mar 5 at 18:24

Bodo

2,271618

answered Mar 5 at 18:24

Bodo

2,271618

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

add a comment |

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

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

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

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Unix & Linux Stack Exchange!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

搜尋此網誌

mjhjmtu