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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/