Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

[Eric W. Biederman]

"Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> writes:

> On Wed, Oct 03, 2012 at 11:43:32AM -0700, Kees Cook wrote:
>> On Wed, Oct 3, 2012 at 9:47 AM, Paul E. McKenney
>> <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>> > On Wed, Oct 03, 2012 at 09:17:02AM -0700, Greg Kroah-Hartman wrote:
>> >> On Wed, Oct 03, 2012 at 06:25:38AM -0700, Paul E. McKenney wrote:
>> >> > On Tue, Oct 02, 2012 at 12:50:42PM -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, 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.
>> >> > >
>> >> > > CC: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
>> >> > > CC: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
>> >> > > CC: Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx>
>> >> > > CC: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
>> >> > > CC: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>> >> > > CC: Frederic Weisbecker <fweisbec@xxxxxxxxx>
>> >> > > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
>> >> > > ---
>> >> > >
>> >> > > This is the first of a series of 202 patches removing EXPERIMENTAL from
>> >> > > all the Kconfigs in the tree. Should I send them all to lkml (with all
>> >> > > the associated CCs), or do people want to cherry-pick changes from my
>> >> > > tree? I don't want to needlessly flood the list.
>> >> > >
>> >> > > http://git.kernel.org/?p=linux/kernel/git/kees/linux.git;a=shortlog;h=refs/heads/experimental
>> >> > >
>> >> > > I figure this patch can stand alone to at least make EXPERIMENTAL go
>> >> > > away from the menus, and give us a taste of what the removal would do
>> >> > > to builds.
>> >> >
>> >> > OK, I will bite...  How should I flag an option that is initially only
>> >> > intended for those willing to take some level of risk?
>> >>
>> >> In the text say "You really don't want to enable this option, use at
>> >> your own risk!"  Or something like that :)
>> >
>> > OK, so the only real hope for experimental features is to refrain from
>> > creating a config option for them, so that people wishing to use them
>> > must modify the code?  Or is the philosophy that we keep things out of
>> > tree until we are comfortable with distros turning them on?
>> 
>> I would expect a simple addition of "this is dangerous/buggy" to the
>> description and "default n" is likely the way to go for that kind of
>> thing. I think the history of CONFIG_EXPERIMENTAL has proven there
>> isn't a sensible way to create a global flag for this kind of thing.
>> To paraphrase Serge: my experimental options are not your experimental
>> options.
>
> That has not proven sufficient for me in the past, RCU_FAST_NO_HZ
> being a case in point.

One option that does work is to add a negative Kconfig dependency such
as "depends on EXT4 = n".  Where what you depend on is something that
distros want.

Where I had a legitimate reason to do that with the user namespace
(aka the code that had not been converted did not compile and was not
safe to use) it worked very well in keeping distros from getting ahead
of them selves, and likewise it works very well for ensuring it got
itself removed as ultimately you want to the two kconfig options to work
together.

>> For example, some of the things that already had the experimental
>> config removed, they left the "(EXPERIMENTAL)" in their config title.
>
> Or I could just make it splat at boot time.  ;-)

Yes.  Treating a truly experimental feature like a deprecated feature
and complaining to the world also seems reasonable, and it seems like
something that would ultimatley get removed as well.

Eric

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