On Thu, Oct 25, 2012 at 9:28 PM, Paul Mundt <let...@linux-sh.org> wrote: > On Tue, Oct 23, 2012 at 01:01:40PM -0700, Kees Cook wrote: >> This config item has not carried much meaning for a while now and is >> almost always enabled by default. As agreed during the Linux kernel >> summit, remove it. >> >> CC: Paul Mundt <let...@linux-sh.org> >> CC: Tejun Heo <t...@kernel.org> >> Signed-off-by: Kees Cook <keesc...@chromium.org> > > While there are cases where it is largely superfluous, we also have > plenty of cases in here that are genuinely experimental features and > generally shouldn't be enabled unless someone is prepared for some > hacking. We can of course replace this with an arch-specific option if > needed, but I disagree with suddenly making experimental features > suddenly appear to be anything other than what they are.
Yeah, things that really are experimental need something, but it hasn't been meaningful to put them behind CONFIG_EXPERIMENTAL. Here's the text from the first patch, which details possible approaches: https://lkml.org/lkml/2012/10/23/878 This config item has not carried much meaning for a while now and is almost always enabled by default (especially in distro builds). As agreed during the Linux kernel summit, it should be removed. As a first step, remove it from being listed, and default it to on. Once it has been removed from all subsystem Kconfigs, it will be dropped entirely. For items that really are experimental, maintainers should use "default n", optionally include "(EXPERIMENTAL)" in the title, and add language to the help text indicating why the item should be considered experimental. For items that are dangerously experimental, the maintainer is encouraged to follow the above title recommendation, add stronger language to the help text, and optionally use (depending on the extent of the danger, from least to most dangerous): printk(), add_taint(TAINT_WARN), add_taint(TAINT_CRAP), WARN_ON(1), and CONFIG_BROKEN. -Kees -- Kees Cook Chrome OS Security -- 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/
