CONFIG_CC_STACKPROTECTOR is no longer experimental
PATCH 1/1 CONFIG_CC_STACKPROTECTOR is no longer experimental
This feature has been around for over 5 years now, so I presume it is no longer considered experimental.
---
Or is there any reason to still consider this an experimental feature?
arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/Kconfig +1 -1
@@ -1525,7 +1525,7 @@ config SECCOMP If unsure, say Y. Only embedded should say N here. config CC_STACKPROTECTOR - bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)" + bool "Enable -fstack-protector buffer overflow detection" ---help--- This option turns on the -fstack-protector GCC feature. This feature puts, at the beginning of functions, a canary value on
Signature · 2 lines
Jean Delvare Suse L3
Quoted 9 lines · Jean Delvare
This feature has been around for over 5 years now, so I presume it is no longer considered experimental.
Signed-off-by Jean Delvare <[email protected]>Cc Ingo Molnar <[email protected]>Cc Arjan van de Ven <[email protected]>Cc Andi Kleen <[email protected]>---
Or is there any reason to still consider this an experimental feature?
I doubt it, but if it is still experimental, it should also have
depends on EXPERIMENTAL
and then it would be nice if kconfig (the software) would add the
" (EXPERIMENTAL)" tag when it sees such a dependency.
Quoted 16 lines
arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/x86/Kconfig +1
-1@@ -1525,7 +1525,7 @@ config SECCOMP If unsure, say Y. Only embedded should say N here. config CC_STACKPROTECTOR - bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)" + bool "Enable -fstack-protector buffer overflow detection" ---help--- This option turns on the -fstack-protector GCC feature. This feature puts, at the beginning of functions, a canary value on
Signature · 1 line
~Randy
Hi Randy,
Quoted 13 lines · Randy Dunlap
Quoted 9 lines · Jean Delvare
This feature has been around for over 5 years now, so I presume it is no longer considered experimental.
Signed-off-by Jean Delvare <[email protected]>Cc Ingo Molnar <[email protected]>Cc Arjan van de Ven <[email protected]>Cc Andi Kleen <[email protected]>---
Or is there any reason to still consider this an experimental feature?
Quoted 2 lines
I doubt it, but if it is still experimental, it should also have
depends on EXPERIMENTAL
Agreed.
Quoted 2 lines
and then it would be nice if kconfig (the software) would add the
" (EXPERIMENTAL)" tag when it sees such a dependency.
Oh yeah, I've been dreaming of this for years now but never found the time to actually look into implementing it. Not sure if I would actually be able to anyway, as it will probably require some Kconfig magic beyond my knowledge.
Signature · 2 lines
Jean Delvare Suse L3
Quoted 21 lines · Jean Delvare
Hi Randy,
Quoted 13 lines · Randy Dunlap
Quoted 9 lines · Jean Delvare
This feature has been around for over 5 years now, so I presume it is no longer considered experimental.
Signed-off-by Jean Delvare <[email protected]>Cc Ingo Molnar <[email protected]>Cc Arjan van de Ven <[email protected]>Cc Andi Kleen <[email protected]>---
Or is there any reason to still consider this an experimental feature?Quoted 2 lines
I doubt it, but if it is still experimental, it should also have
depends on EXPERIMENTALAgreed.
Quoted 7 lines
Quoted 2 lines
and then it would be nice if kconfig (the software) would add the
" (EXPERIMENTAL)" tag when it sees such a dependency.Oh yeah, I've been dreaming of this for years now but never found the time to actually look into implementing it. Not sure if I would actually be able to anyway, as it will probably require some
Kconfigmagic beyond my knowledge.
I rather just retire the whole concept of "Experimental".
it's really utterly meaningless in practice anyway.
Quoted 3 lines · Arjan van de Ven
I rather just retire the whole concept of "Experimental".
it's really utterly meaningless in practice anyway.
See Russell King's quick survey in https://lkml.org/lkml/2012/1/18/397 :
almost all defconfigs had CONFIG_EXPERIMENTAL enabled. I didn't recheck since I'm sure little has changed. That macro and the related Kconfig symbol seem indeed meaningless.
Paul Bolle
Hi all,
Quoted 9 lines · Paul Bolle
Quoted 3 lines · Arjan van de Ven
I rather just retire the whole concept of "Experimental".
it's really utterly meaningless in practice anyway.
See Russell King's quick survey in https://lkml.org/lkml/2012/1/18/397 :
almost all defconfigs hadCONFIG_EXPERIMENTALenabled. I didn't recheck since I'm sure little has changed. That macro and the relatedKconfigsymbol seem indeed meaningless.
I admit I have CONFIG_EXPERIMENTAL enabled on all my systems as well, even the ones running an enterprise grade flavor of GNU/Linux.
This isn't necessarily surprising. Having to make decisions at build time has always been an issue for distributions. The proper way for distributions to deal with experimental drivers is to package them separately and/or blacklist them by default. For experimental options, best is to make them tunable at run time, for example using module parameters.
As for options still depending on EXPERIMENTAL when they no longer should, this can partly be explained when the EXPERIMENTAL dependency doesn't show up in the short description. This is the case of CONFIG_CC_STACKPROTECTOR. As everybody has CONFIG_EXPERIMENTAL enabled, nobody notices the dependency.
The existence of CONFIG_EXPERIMENTAL may give developers the impression that depending on it is sufficient and the right thing to do for experimental drivers/features. That would be true if depending on CONFIG_EXPERIMENTAL would automatically add "(EXPERIMENTAL)" to the short description, as Randy and I were discussing previously, but this was never implemented.
If we all agree that CONFIG_EXPERIMENTAL is no longer a good idea, then I'm fine dropping it. I'm always happy to see kernel configuration options go. Then options which used to depend on it and did not have "(EXPERIMENTAL)" in their short description should have it appended. These options should also default to N (but I think this is the default default if none is specified?) Maybe a task for kernel janitors?
Back to my initial question, am I right to assume that CONFIG_CC_STACKPROTECTOR is no longer experimental and can be enabled in distribution kernels?
Thanks,
Signature · 2 lines
Jean Delvare Suse L3
Quoted 5 lines · Jean Delvare
As for options still depending on EXPERIMENTAL when they no longer should, this can partly be explained when the EXPERIMENTAL dependency doesn't show up in the short description. This is the case of
CONFIG_CC_STACKPROTECTOR. As everybody hasCONFIG_EXPERIMENTALenabled, nobody notices the dependency.
Sorry, I got it the wrong way around (not that it necessarily matters for the general picture): CONFIG_CC_STACKPROTECTOR no longer depends on CONFIG_EXPERIMENTAL, but it does still have "(EXPERIMENTAL)" in its short description. So there is no excuse for us not noticing, assuming the feature is really no longer experimental.
Signature · 2 lines
Jean Delvare Suse L3
Quoted 3 lines · Jean Delvare
Back to my initial question, am I right to assume that
CONFIG_CC_STACKPROTECTORis no longer experimental and can be enabled in distribution kernels?
it HAS been enabled in distribution kernels for YEARS. so yes.
[tip:x86/urgent] x86: CONFIG_CC_STACKPROTECTOR= y is no longer experimental
In reply to Jean DelvareCommit-ID: 2a8ac745e3171889d364235b8203342e28526d2c Gitweb: http://git.kernel.org/tip/2a8ac745e3171889d364235b8203342e28526d2c Author: Jean Delvare <[email protected]> AuthorDate: Fri, 6 Jul 2012 16:08:25 +0200 Committer: Ingo Molnar <[email protected]> CommitDate: Mon, 9 Jul 2012 13:59:53 +0200
x86: CONFIG_CC_STACKPROTECTOR=y is no longer experimental
This feature has been around for over 5 years now, and has no CONFIG_EXPERIMENTAL dependency anymore, so remove the '(EXPERIMENTAL)' tag from the help text as well.
--- arch/x86/Kconfig | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/x86/Kconfig +1 -1
@@ -1525,7 +1525,7 @@ config SECCOMP If unsure, say Y. Only embedded should say N here. config CC_STACKPROTECTOR - bool "Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)" + bool "Enable -fstack-protector buffer overflow detection" ---help--- This option turns on the -fstack-protector GCC feature. This feature puts, at the beginning of functions, a canary value on