[PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[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 <jdelvare@suse.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
---
Or is there any reason to still consider this an experimental feature?

 arch/x86/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-3.5-rc5.orig/arch/x86/Kconfig	2012-06-05 16:22:58.000000000 +0200
+++ linux-3.5-rc5/arch/x86/Kconfig	2012-07-06 15:32:55.660276577 +0200
@@ -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

-- 
Jean Delvare
Suse L3

Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[Randy Dunlap]

On 07/06/2012 07:08 AM, Jean Delvare wrote:

> This feature has been around for over 5 years now, so I presume it is
> no longer considered experimental.
> 
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Arjan van de Ven <arjan@linux.intel.com>
> Cc: Andi Kleen <andi@firstfloor.org>
> ---
> 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.


> 
>  arch/x86/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-3.5-rc5.orig/arch/x86/Kconfig	2012-06-05 16:22:58.000000000 +0200
> +++ linux-3.5-rc5/arch/x86/Kconfig	2012-07-06 15:32:55.660276577 +0200
> @@ -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
> 



-- 
~Randy

Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[Jean Delvare]

Hi Randy,

Le vendredi 06 juillet 2012 à 10:23 -0700, Randy Dunlap a écrit :
> On 07/06/2012 07:08 AM, Jean Delvare wrote:
> 
> > This feature has been around for over 5 years now, so I presume it is
> > no longer considered experimental.
> > 
> > Signed-off-by: Jean Delvare <jdelvare@suse.de>
> > Cc: Ingo Molnar <mingo@redhat.com>
> > Cc: Arjan van de Ven <arjan@linux.intel.com>
> > Cc: Andi Kleen <andi@firstfloor.org>
> > ---
> > 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

Agreed.

> 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.


-- 
Jean Delvare
Suse L3

Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[Arjan van de Ven]

On 7/6/2012 10:57 AM, Jean Delvare wrote:
> Hi Randy,
> 
> Le vendredi 06 juillet 2012 à 10:23 -0700, Randy Dunlap a écrit :
>> On 07/06/2012 07:08 AM, Jean Delvare wrote:
>>
>>> This feature has been around for over 5 years now, so I presume it is
>>> no longer considered experimental.
>>>
>>> Signed-off-by: Jean Delvare <jdelvare@suse.de>
>>> Cc: Ingo Molnar <mingo@redhat.com>
>>> Cc: Arjan van de Ven <arjan@linux.intel.com>
>>> Cc: Andi Kleen <andi@firstfloor.org>
>>> ---
>>> 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
> 
> Agreed.
> 
>> 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.

I rather just retire the whole concept of "Experimental".

it's really utterly meaningless in practice anyway.

Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[Paul Bolle]

On Fri, 2012-07-06 at 10:58 -0700, Arjan van de Ven wrote:
> 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

Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[Jean Delvare]

Hi all,

Le vendredi 06 juillet 2012 à 22:19 +0200, Paul Bolle a écrit :
> On Fri, 2012-07-06 at 10:58 -0700, Arjan van de Ven wrote:
> > 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.

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,
-- 
Jean Delvare
Suse L3

Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[Jean Delvare]

Le lundi 09 juillet 2012 à 09:56 +0200, Jean Delvare a écrit :
> 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.

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.

-- 
Jean Delvare
Suse L3

Re: [PATCH] CONFIG_CC_STACKPROTECTOR is no longer experimental

[Arjan van de Ven]

On 7/9/2012 12:56 AM, Jean Delvare wrote:

> 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?

it HAS been enabled in distribution kernels for YEARS.
so yes.

[tip:x86/urgent] x86: CONFIG_CC_STACKPROTECTOR= y is no longer experimental

[tip-bot for Jean Delvare]

Commit-ID:  2a8ac745e3171889d364235b8203342e28526d2c
Gitweb:     http://git.kernel.org/tip/2a8ac745e3171889d364235b8203342e28526d2c
Author:     Jean Delvare <jdelvare@suse.de>
AuthorDate: Fri, 6 Jul 2012 16:08:25 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
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.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Link: http://lkml.kernel.org/r/1341583705.4655.18.camel@amber.site
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c70684f..b03fe17 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -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