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
#ifdefsome 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 theifdefis 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 CrewsNick Crews
1011
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
#ifdefsome 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 theifdefis 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 CrewsNick 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
#ifdefsome 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 theifdefis 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 CrewsNick 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
#ifdefsome 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 theifdefis 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
linux kernel linux-kernel configuration
asked Mar 5 at 16:34
Nick CrewsNick Crews
1011
asked Mar 5 at 16:34
Nick CrewsNick Crews
1011
asked Mar 5 at 16:34
Nick CrewsNick Crews
1011
asked Mar 5 at 16:34
Nick CrewsNick Crews
1011
asked Mar 5 at 16:34
Nick CrewsNick Crews
1011
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
1
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
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
@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
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
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
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.
answered Mar 5 at 18:24
BodoBodo
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
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.
answered Mar 5 at 18:24
BodoBodo
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.
answered Mar 5 at 18:24
BodoBodo
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.
answered Mar 5 at 18:24
BodoBodo
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.
answered Mar 5 at 18:24
BodoBodo
2,271618
edited Mar 11 at 11:00
answered Mar 5 at 18:24
BodoBodo
2,271618
answered Mar 5 at 18:24
BodoBodo
2,271618
answered Mar 5 at 18:24
BodoBodo
2,271618
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
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
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
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 |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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