LinuxLists.cc - [PATCH] make CONFIG_EXPERIMENTAL invisible and default

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

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 <[email protected]>
> CC: "Eric W. Biederman" <[email protected]>
> CC: Serge Hallyn <[email protected]>
> CC: "Paul E. McKenney" <[email protected]>
> CC: Andrew Morton <[email protected]>
> CC: Frederic Weisbecker <[email protected]>
> Signed-off-by: Kees Cook <[email protected]>
> ---
>
> 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?

Thanx, Paul

> Thanks,
>
> -Kees
>
> ---
> init/Kconfig | 31 ++-----------------------------
> 1 file changed, 2 insertions(+), 29 deletions(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index cb003a3..f6f8146 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -33,35 +33,8 @@ config BUILDTIME_EXTABLE_SORT
> menu "General setup"
>
> config EXPERIMENTAL
> - bool "Prompt for development and/or incomplete code/drivers"
> - ---help---
> - Some of the various things that Linux supports (such as network
> - drivers, file systems, network protocols, etc.) can be in a state
> - of development where the functionality, stability, or the level of
> - testing is not yet high enough for general use. This is usually
> - known as the "alpha-test" phase among developers. If a feature is
> - currently in alpha-test, then the developers usually discourage
> - uninformed widespread use of this feature by the general public to
> - avoid "Why doesn't this work?" type mail messages. However, active
> - testing and use of these systems is welcomed. Just be aware that it
> - may not meet the normal level of reliability or it may fail to work
> - in some special cases. Detailed bug reports from people familiar
> - with the kernel internals are usually welcomed by the developers
> - (before submitting bug reports, please read the documents
> - <file:README>, <file:MAINTAINERS>, <file:REPORTING-BUGS>,
> - <file:Documentation/BUG-HUNTING>, and
> - <file:Documentation/oops-tracing.txt> in the kernel source).
> -
> - This option will also make obsoleted drivers available. These are
> - drivers that have been replaced by something else, and/or are
> - scheduled to be removed in a future kernel release.
> -
> - Unless you intend to help test and develop a feature or driver that
> - falls into this category, or you have a situation that requires
> - using these features, you should probably say N here, which will
> - cause the configurator to present you with fewer choices. If
> - you say Y here, you will be offered the choice of using features or
> - drivers that are currently considered to be in the alpha-test phase.
> + bool
> + default y
>
> config BROKEN
> bool
> --
> 1.7.9.5
>
>
> --
> Kees Cook
> Chrome OS Security
>

2012-10-03 16:15:38

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 3, 2012 at 6:25 AM, Paul E. McKenney
<[email protected]> 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 <[email protected]>
>> CC: "Eric W. Biederman" <[email protected]>
>> CC: Serge Hallyn <[email protected]>
>> CC: "Paul E. McKenney" <[email protected]>
>> CC: Andrew Morton <[email protected]>
>> CC: Frederic Weisbecker <[email protected]>
>> Signed-off-by: Kees Cook <[email protected]>
>> ---
>>
>> 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?

I'm not sure I understand what you mean? The intention of removing
EXPERIMENTAL is effectively like turning it on everywhere, so this
first patch does that. As we go forward we can remove the its
redundant use in all the Kconfigs, until it is finally removed for
real.

-Kees

--
Kees Cook
Chrome OS Security

2012-10-03 16:16:52

by Serge Hallyn

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

Quoting Paul E. McKenney ([email protected]):
> 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 <[email protected]>
> > CC: "Eric W. Biederman" <[email protected]>
> > CC: Serge Hallyn <[email protected]>
> > CC: "Paul E. McKenney" <[email protected]>
> > CC: Andrew Morton <[email protected]>
> > CC: Frederic Weisbecker <[email protected]>
> > Signed-off-by: Kees Cook <[email protected]>
> > ---
> >
> > 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?

Sadly, the point is that EXPERIMENTAL is enabled in all distros and by
most users, so you *could* flag your feature CONFIG_EXPERIMENTAL, but
the only thing taht might accomplish is making you feel ok to be less
careful.

Of course, an alternative to this patch would be a purging - pull
the CONFIG_EXPERIMENTAL tag from all options which anyone might be
wanting to use by default. Then let CONFIG_EXPERIMENTAL serve its
original purpose.

-serge

2012-10-03 16:17:06

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

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 <[email protected]>
> > CC: "Eric W. Biederman" <[email protected]>
> > CC: Serge Hallyn <[email protected]>
> > CC: "Paul E. McKenney" <[email protected]>
> > CC: Andrew Morton <[email protected]>
> > CC: Frederic Weisbecker <[email protected]>
> > Signed-off-by: Kees Cook <[email protected]>
> > ---
> >
> > 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 :)

greg k-h

2012-10-03 16:44:00

by Josh Boyer

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 3, 2012 at 12:15 PM, Kees Cook <[email protected]> wrote:
> On Wed, Oct 3, 2012 at 6:25 AM, Paul E. McKenney
> <[email protected]> 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 <[email protected]>
>>> CC: "Eric W. Biederman" <[email protected]>
>>> CC: Serge Hallyn <[email protected]>
>>> CC: "Paul E. McKenney" <[email protected]>
>>> CC: Andrew Morton <[email protected]>
>>> CC: Frederic Weisbecker <[email protected]>
>>> Signed-off-by: Kees Cook <[email protected]>
>>> ---
>>>
>>> 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?
>
> I'm not sure I understand what you mean? The intention of removing
> EXPERIMENTAL is effectively like turning it on everywhere, so this
> first patch does that. As we go forward we can remove the its
> redundant use in all the Kconfigs, until it is finally removed for
> real.

He's asking "how do I add a feature/option into Linus' tree that I'm
really not ready for random people and/or distros to enable". The
short answer is "don't merge that into Linus' tree" I guess. Keep it
in a git branch or patchset somewhere else. Perhaps those willing to
take the risk are also willing to apply the patches?

josh

2012-10-03 17:13:23

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

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 <[email protected]>
> > > CC: "Eric W. Biederman" <[email protected]>
> > > CC: Serge Hallyn <[email protected]>
> > > CC: "Paul E. McKenney" <[email protected]>
> > > CC: Andrew Morton <[email protected]>
> > > CC: Frederic Weisbecker <[email protected]>
> > > Signed-off-by: Kees Cook <[email protected]>
> > > ---
> > >
> > > 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?

Thanx, Paul

2012-10-03 17:21:46

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 09:47:12AM -0700, Paul E. McKenney 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 <[email protected]>
> > > > CC: "Eric W. Biederman" <[email protected]>
> > > > CC: Serge Hallyn <[email protected]>
> > > > CC: "Paul E. McKenney" <[email protected]>
> > > > CC: Andrew Morton <[email protected]>
> > > > CC: Frederic Weisbecker <[email protected]>
> > > > Signed-off-by: Kees Cook <[email protected]>
> > > > ---
> > > >
> > > > 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 think that should have been your philosophy for a long time, as they
turn on everything, and I don't blame them. Why would we have included
it in the kernel tree, unless we wanted people to use the option?

greg k-h

2012-10-03 17:46:25

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 10:21:42AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 03, 2012 at 09:47:12AM -0700, Paul E. McKenney 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 <[email protected]>
> > > > > CC: "Eric W. Biederman" <[email protected]>
> > > > > CC: Serge Hallyn <[email protected]>
> > > > > CC: "Paul E. McKenney" <[email protected]>
> > > > > CC: Andrew Morton <[email protected]>
> > > > > CC: Frederic Weisbecker <[email protected]>
> > > > > Signed-off-by: Kees Cook <[email protected]>
> > > > > ---
> > > > >
> > > > > 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 think that should have been your philosophy for a long time, as they
> turn on everything, and I don't blame them.
> Why would we have included
> it in the kernel tree, unless we wanted people to use the option?

A solution could be to add that option under CONFIG_DEBUG_KERNEL and specify
that it must only be enabled by developers for specific reasons (overhead,
security). CONFIG_PROVE_LOCKING falls into that category, right?

We have CONFIG_RCU_USER_QS that is a specific case. It's an intermediate state
before we implement a true CONFIG_NO_HZ_FULL. But the option is useless on its
own for users. Worse, it introduces a real overhead. OTOH we want it to be upstream
to make the development of full tickless feature more incremental.

Perhaps we should put that under CONFIG_DEBUG_KERNEL.

2012-10-03 17:47:11

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 10:21:42AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 03, 2012 at 09:47:12AM -0700, Paul E. McKenney 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 <[email protected]>
> > > > > CC: "Eric W. Biederman" <[email protected]>
> > > > > CC: Serge Hallyn <[email protected]>
> > > > > CC: "Paul E. McKenney" <[email protected]>
> > > > > CC: Andrew Morton <[email protected]>
> > > > > CC: Frederic Weisbecker <[email protected]>
> > > > > Signed-off-by: Kees Cook <[email protected]>
> > > > > ---
> > > > >
> > > > > 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 think that should have been your philosophy for a long time, as they
> turn on everything, and I don't blame them. Why would we have included
> it in the kernel tree, unless we wanted people to use the option?

Because some sizeable group of people would like to use the option,
but it is not helpful to many others?

Thanx, Paul

2012-10-03 18:02:17

by Serge Hallyn

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

Quoting Paul E. McKenney ([email protected]):
> On Wed, Oct 03, 2012 at 10:21:42AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Oct 03, 2012 at 09:47:12AM -0700, Paul E. McKenney 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 <[email protected]>
> > > > > > CC: "Eric W. Biederman" <[email protected]>
> > > > > > CC: Serge Hallyn <[email protected]>
> > > > > > CC: "Paul E. McKenney" <[email protected]>
> > > > > > CC: Andrew Morton <[email protected]>
> > > > > > CC: Frederic Weisbecker <[email protected]>
> > > > > > Signed-off-by: Kees Cook <[email protected]>
> > > > > > ---
> > > > > >
> > > > > > 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 think that should have been your philosophy for a long time, as they
> > turn on everything, and I don't blame them. Why would we have included
> > it in the kernel tree, unless we wanted people to use the option?
>
> Because some sizeable group of people would like to use the option,
> but it is not helpful to many others?

The way that is worded, that wouldn't sound like CONFIG_EXPERIMENTAL
even if that worked the way we wanted. Just a clearly worded separate
config option for your feature would be best in that case. Yes there
are tons of options to wade through, but you can't make
CONFIG_EXPERIMENTAL a binary for what you describe, since the
experimental options i'd want (user namespaces, etc) would not be the
same ones you'd want.

-serge

2012-10-03 18:23:53

by Josh Boyer

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 3, 2012 at 1:46 PM, Frederic Weisbecker <[email protected]> wrote:
> On Wed, Oct 03, 2012 at 10:21:42AM -0700, Greg Kroah-Hartman wrote:
>> On Wed, Oct 03, 2012 at 09:47:12AM -0700, Paul E. McKenney 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 <[email protected]>
>> > > > > CC: "Eric W. Biederman" <[email protected]>
>> > > > > CC: Serge Hallyn <[email protected]>
>> > > > > CC: "Paul E. McKenney" <[email protected]>
>> > > > > CC: Andrew Morton <[email protected]>
>> > > > > CC: Frederic Weisbecker <[email protected]>
>> > > > > Signed-off-by: Kees Cook <[email protected]>
>> > > > > ---
>> > > > >
>> > > > > 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 think that should have been your philosophy for a long time, as they
>> turn on everything, and I don't blame them.
>> Why would we have included
>> it in the kernel tree, unless we wanted people to use the option?
>
> A solution could be to add that option under CONFIG_DEBUG_KERNEL and specify
> that it must only be enabled by developers for specific reasons (overhead,
> security). CONFIG_PROVE_LOCKING falls into that category, right?

No. Fedora runs with that enabled in our development repositories. To
be honest, I think we're one of the only users of it given we hit bugs
in released kernels, etc. We actually _want_ the bug reports it finds.

josh

2012-10-03 18:43:34

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 3, 2012 at 9:47 AM, Paul E. McKenney
<[email protected]> 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 <[email protected]>
>> > > CC: "Eric W. Biederman" <[email protected]>
>> > > CC: Serge Hallyn <[email protected]>
>> > > CC: "Paul E. McKenney" <[email protected]>
>> > > CC: Andrew Morton <[email protected]>
>> > > CC: Frederic Weisbecker <[email protected]>
>> > > Signed-off-by: Kees Cook <[email protected]>
>> > > ---
>> > >
>> > > 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.

For example, some of the things that already had the experimental
config removed, they left the "(EXPERIMENTAL)" in their config title.

-Kees

--
Kees Cook
Chrome OS Security

2012-10-03 19:08:14

by David Lang

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, 3 Oct 2012, Kees Cook wrote:

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

Remember that new features/drivers should be defaulting to 'n' in any
case. It's a rare feature that has no drawbacks (if only in the kernel
size, which is an issue for small devices). If there really are no
drawbacks to something, why have it be an option at all?

David Lang

2012-10-03 19:55:49

by Dave Jones

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 07:46:18PM +0200, Frederic Weisbecker wrote:
> > it in the kernel tree, unless we wanted people to use the option?
>
> A solution could be to add that option under CONFIG_DEBUG_KERNEL and specify
> that it must only be enabled by developers for specific reasons (overhead,
> security). CONFIG_PROVE_LOCKING falls into that category, right?
>
> We have CONFIG_RCU_USER_QS that is a specific case. It's an intermediate state
> before we implement a true CONFIG_NO_HZ_FULL. But the option is useless on its
> own for users. Worse, it introduces a real overhead. OTOH we want it to be upstream
> to make the development of full tickless feature more incremental.
>
> Perhaps we should put that under CONFIG_DEBUG_KERNEL.

Overloading an existing config option for something unrelated seems unpleasant to me.
It will only take a few people to start doing this, before it turns into a landslide
where everyone ends up with DEBUG_KERNEL set.
And what of people who already have DEBUG_KERNEL set ?

Just state what you wrote above in the kconfig.
Currently, RCU_USER_QS says nothing about the fact that it's work in progress.

The missing part that I don't have an answer for however, is what happens
when you deem this production ready? Distro maintainers won't notice the
kconfig text changing. But perhaps that's a good thing, and will lead to things
only being enabled when people explicitly ask for them in distros.

Alternatively, if you really do want to go the path of a new config option,
perhaps CONFIG_NOT_DISTRO_READY would spell things out more clearly.
EXPERIMENTAL is such a wasteland it would take too much manpower to audit
every case, and update accordingly, but scorching the earth and starting
afresh might be feasible.

Dave

2012-10-03 20:12:02

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 03:36:53PM -0400, Dave Jones wrote:
> On Wed, Oct 03, 2012 at 07:46:18PM +0200, Frederic Weisbecker wrote:
> > > it in the kernel tree, unless we wanted people to use the option?
> >
> > A solution could be to add that option under CONFIG_DEBUG_KERNEL and specify
> > that it must only be enabled by developers for specific reasons (overhead,
> > security). CONFIG_PROVE_LOCKING falls into that category, right?
> >
> > We have CONFIG_RCU_USER_QS that is a specific case. It's an intermediate state
> > before we implement a true CONFIG_NO_HZ_FULL. But the option is useless on its
> > own for users. Worse, it introduces a real overhead. OTOH we want it to be upstream
> > to make the development of full tickless feature more incremental.
> >
> > Perhaps we should put that under CONFIG_DEBUG_KERNEL.
>
> Overloading an existing config option for something unrelated seems unpleasant to me.
> It will only take a few people to start doing this, before it turns into a landslide
> where everyone ends up with DEBUG_KERNEL set.
> And what of people who already have DEBUG_KERNEL set ?
>
> Just state what you wrote above in the kconfig.
> Currently, RCU_USER_QS says nothing about the fact that it's work in progress.

Fair point!

> The missing part that I don't have an answer for however, is what happens
> when you deem this production ready? Distro maintainers won't notice the
> kconfig text changing. But perhaps that's a good thing, and will lead to things
> only being enabled when people explicitly ask for them in distros.
>
> Alternatively, if you really do want to go the path of a new config option,
> perhaps CONFIG_NOT_DISTRO_READY would spell things out more clearly.
> EXPERIMENTAL is such a wasteland it would take too much manpower to audit
> every case, and update accordingly, but scorching the earth and starting
> afresh might be feasible.

Heh! We might just plan to scorch the earth and start afresh every few
years. That might actually work... ;-)

Thanx, Paul

2012-10-03 20:13:27

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

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
> <[email protected]> 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 <[email protected]>
> >> > > CC: "Eric W. Biederman" <[email protected]>
> >> > > CC: Serge Hallyn <[email protected]>
> >> > > CC: "Paul E. McKenney" <[email protected]>
> >> > > CC: Andrew Morton <[email protected]>
> >> > > CC: Frederic Weisbecker <[email protected]>
> >> > > Signed-off-by: Kees Cook <[email protected]>
> >> > > ---
> >> > >
> >> > > 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.

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

Thanx, Paul

2012-10-03 21:31:34

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 11:43:32AM -0700, Kees Cook wrote:
> 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.

Agreed.

> 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.
> For example, some of the things that already had the experimental
> config removed, they left the "(EXPERIMENTAL)" in their config title.

Right.

2012-10-03 21:43:45

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 03:36:53PM -0400, Dave Jones wrote:
> On Wed, Oct 03, 2012 at 07:46:18PM +0200, Frederic Weisbecker wrote:
> > > it in the kernel tree, unless we wanted people to use the option?
> >
> > A solution could be to add that option under CONFIG_DEBUG_KERNEL and specify
> > that it must only be enabled by developers for specific reasons (overhead,
> > security). CONFIG_PROVE_LOCKING falls into that category, right?
> >
> > We have CONFIG_RCU_USER_QS that is a specific case. It's an intermediate state
> > before we implement a true CONFIG_NO_HZ_FULL. But the option is useless on its
> > own for users. Worse, it introduces a real overhead. OTOH we want it to be upstream
> > to make the development of full tickless feature more incremental.
> >
> > Perhaps we should put that under CONFIG_DEBUG_KERNEL.
>
> Overloading an existing config option for something unrelated seems unpleasant to me.
> It will only take a few people to start doing this, before it turns into a landslide
> where everyone ends up with DEBUG_KERNEL set.
> And what of people who already have DEBUG_KERNEL set ?

Sorry, by wording wasn't clear. I didn't mean overloading CONFIG_DEBUG_KERNEL but
rather depend on it.

>
> Just state what you wrote above in the kconfig.
> Currently, RCU_USER_QS says nothing about the fact that it's work in progress.

Yeah I much prefer that. I'll add some details on the Kconfig.

> The missing part that I don't have an answer for however, is what happens
> when you deem this production ready? Distro maintainers won't notice the
> kconfig text changing. But perhaps that's a good thing, and will lead to things
> only being enabled when people explicitly ask for them in distros.

That Kconfig option is likely going to disappear inside a new CONFIG_NO_HZ_FULL that
will enables individual features like RCU user mode and stuffs.

And if it stays, it will be enabled by CONFIG_NO_HZ_FULL. So it's not an option
anybody will ever have to deal with directly.

> Alternatively, if you really do want to go the path of a new config option,
> perhaps CONFIG_NOT_DISTRO_READY would spell things out more clearly.
> EXPERIMENTAL is such a wasteland it would take too much manpower to audit
> every case, and update accordingly, but scorching the earth and starting
> afresh might be feasible.

CONFIG_STAGING already does that kind of thing I guess. Although I suspect people
are reluctant with core features in -staging.

2012-10-03 22:23:37

by Eric W. Biederman

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

"Paul E. McKenney" <[email protected]> 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
>> <[email protected]> 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 <[email protected]>
>> >> > > CC: "Eric W. Biederman" <[email protected]>
>> >> > > CC: Serge Hallyn <[email protected]>
>> >> > > CC: "Paul E. McKenney" <[email protected]>
>> >> > > CC: Andrew Morton <[email protected]>
>> >> > > CC: Frederic Weisbecker <[email protected]>
>> >> > > Signed-off-by: Kees Cook <[email protected]>
>> >> > > ---
>> >> > >
>> >> > > 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

2012-10-03 23:28:47

by Guenter Roeck

[permalink] [raw]

Subject: Re: make CONFIG_EXPERIMENTAL invisible and default

On Tue, Oct 02, 2012 at 07:50:42PM -0000, 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 <[email protected]>
> CC: "Eric W. Biederman" <[email protected]>
> CC: Serge Hallyn <[email protected]>
> CC: "Paul E. McKenney" <[email protected]>
> CC: Andrew Morton <[email protected]>
> CC: Frederic Weisbecker <[email protected]>
> Signed-off-by: Kees Cook <[email protected]>
> Acked-by: Serge Hallyn <[email protected]>
>
> ---
> 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 cherry-picked the hwmon/pmbus patch (commit 41c5b6bb).

Guenter

2012-10-03 23:33:22

[permalink] [raw]

Subject: Re: make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 3, 2012 at 4:29 PM, Guenter Roeck <[email protected]> wrote:
> On Tue, Oct 02, 2012 at 07:50:42PM -0000, 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 <[email protected]>
>> CC: "Eric W. Biederman" <[email protected]>
>> CC: Serge Hallyn <[email protected]>
>> CC: "Paul E. McKenney" <[email protected]>
>> CC: Andrew Morton <[email protected]>
>> CC: Frederic Weisbecker <[email protected]>
>> Signed-off-by: Kees Cook <[email protected]>
>> Acked-by: Serge Hallyn <[email protected]>
>>
>> ---
>> 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 cherry-picked the hwmon/pmbus patch (commit 41c5b6bb).

Great, thanks!

-Kees

--
Kees Cook
Chrome OS Security

2012-10-03 23:36:24

by Guenter Roeck

[permalink] [raw]

Subject: Re: make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 04:33:21PM -0700, Kees Cook wrote:
> On Wed, Oct 3, 2012 at 4:29 PM, Guenter Roeck <[email protected]> wrote:
> > On Tue, Oct 02, 2012 at 07:50:42PM -0000, 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 <[email protected]>
> >> CC: "Eric W. Biederman" <[email protected]>
> >> CC: Serge Hallyn <[email protected]>
> >> CC: "Paul E. McKenney" <[email protected]>
> >> CC: Andrew Morton <[email protected]>
> >> CC: Frederic Weisbecker <[email protected]>
> >> Signed-off-by: Kees Cook <[email protected]>
> >> Acked-by: Serge Hallyn <[email protected]>
> >>
> >> ---
> >> 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 cherry-picked the hwmon/pmbus patch (commit 41c5b6bb).
>
> Great, thanks!
>
I also picked the Documentation/hwmon patch (fbe3d657620).

Guenter

2012-10-04 00:12:09

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 03:23:27PM -0700, Eric W. Biederman wrote:
> "Paul E. McKenney" <[email protected]> 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
> >> <[email protected]> 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 <[email protected]>
> >> >> > > CC: "Eric W. Biederman" <[email protected]>
> >> >> > > CC: Serge Hallyn <[email protected]>
> >> >> > > CC: "Paul E. McKenney" <[email protected]>
> >> >> > > CC: Andrew Morton <[email protected]>
> >> >> > > CC: Frederic Weisbecker <[email protected]>
> >> >> > > Signed-off-by: Kees Cook <[email protected]>
> >> >> > > ---
> >> >> > >
> >> >> > > 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.

Cute! ;-)

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

Either removed or fixed, as the case may be.

Thanx, Paul

2012-10-04 01:55:51

by Matthew Garrett

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 01:03:14PM -0700, Paul E. McKenney wrote:

> That has not proven sufficient for me in the past, RCU_FAST_NO_HZ
> being a case in point.

Taint the kernel at boot time? That'd be sufficient to force distros to
disable it.

--
Matthew Garrett | [email protected]

2012-10-04 14:32:44

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 03, 2012 at 11:43:37PM +0200, Frederic Weisbecker wrote:
> On Wed, Oct 03, 2012 at 03:36:53PM -0400, Dave Jones wrote:
> > On Wed, Oct 03, 2012 at 07:46:18PM +0200, Frederic Weisbecker wrote:
> > > > it in the kernel tree, unless we wanted people to use the option?
> > >
> > > A solution could be to add that option under CONFIG_DEBUG_KERNEL and specify
> > > that it must only be enabled by developers for specific reasons (overhead,
> > > security). CONFIG_PROVE_LOCKING falls into that category, right?
> > >
> > > We have CONFIG_RCU_USER_QS that is a specific case. It's an intermediate state
> > > before we implement a true CONFIG_NO_HZ_FULL. But the option is useless on its
> > > own for users. Worse, it introduces a real overhead. OTOH we want it to be upstream
> > > to make the development of full tickless feature more incremental.
> > >
> > > Perhaps we should put that under CONFIG_DEBUG_KERNEL.
> >
> > Overloading an existing config option for something unrelated seems unpleasant to me.
> > It will only take a few people to start doing this, before it turns into a landslide
> > where everyone ends up with DEBUG_KERNEL set.
> > And what of people who already have DEBUG_KERNEL set ?
>
> Sorry, by wording wasn't clear. I didn't mean overloading CONFIG_DEBUG_KERNEL but
> rather depend on it.
>
> >
> > Just state what you wrote above in the kconfig.
> > Currently, RCU_USER_QS says nothing about the fact that it's work in progress.
>
> Yeah I much prefer that. I'll add some details on the Kconfig.
>
> > The missing part that I don't have an answer for however, is what happens
> > when you deem this production ready? Distro maintainers won't notice the
> > kconfig text changing. But perhaps that's a good thing, and will lead to things
> > only being enabled when people explicitly ask for them in distros.
>
> That Kconfig option is likely going to disappear inside a new CONFIG_NO_HZ_FULL that
> will enables individual features like RCU user mode and stuffs.
>
> And if it stays, it will be enabled by CONFIG_NO_HZ_FULL. So it's not an option
> anybody will ever have to deal with directly.
>
> > Alternatively, if you really do want to go the path of a new config option,
> > perhaps CONFIG_NOT_DISTRO_READY would spell things out more clearly.
> > EXPERIMENTAL is such a wasteland it would take too much manpower to audit
> > every case, and update accordingly, but scorching the earth and starting
> > afresh might be feasible.
>
> CONFIG_STAGING already does that kind of thing I guess. Although I suspect people
> are reluctant with core features in -staging.

Well, it would certainly be possible to include a file from a
drivers/staging/rcu directory or some such. As you say, I am not sure
how Greg KH would react to such a patch, though. ;-)

I guess that the lesson I am learning here is that the nocb patch
needs to go into the -rt patchset rather than directly into mainline.
Though Dave Jones's thought of tainting the kernel at boot time
sounds interesting as well.

Thanx, Paul

2012-10-04 14:33:23

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Thu, Oct 04, 2012 at 02:55:39AM +0100, Matthew Garrett wrote:
> On Wed, Oct 03, 2012 at 01:03:14PM -0700, Paul E. McKenney wrote:
>
> > That has not proven sufficient for me in the past, RCU_FAST_NO_HZ
> > being a case in point.
>
> Taint the kernel at boot time? That'd be sufficient to force distros to
> disable it.

Cool! That does sound much more socially responsible than my thought
of forcing a splat (e.g., WARN_ON(1)) during boot. ;-)

Thanx, Paul

2012-10-05 16:46:58

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Thu, Oct 04, 2012 at 07:31:50AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 04, 2012 at 02:55:39AM +0100, Matthew Garrett wrote:
> > On Wed, Oct 03, 2012 at 01:03:14PM -0700, Paul E. McKenney wrote:
> >
> > > That has not proven sufficient for me in the past, RCU_FAST_NO_HZ
> > > being a case in point.
> >
> > Taint the kernel at boot time? That'd be sufficient to force distros to
> > disable it.
>
> Cool! That does sound much more socially responsible than my thought
> of forcing a splat (e.g., WARN_ON(1)) during boot. ;-)

So, from what I can see, here is the list of the ways of warning distros
off of a given kernel config option, taken in terms of CONFIG_RCU_USER_QS:

1. Make CONFIG_RCU_USER_QS depend on CONFIG_BROKEN.

It sounds to me like distros would avoid adding this (do they?),
but tester would probably avoid it as well.

2. Make CONFIG_RCU_USER_QS depend on CONFIG_STAGING.

As Frederic noted, this is more of a driver thing than a
core-kernel thing, so probably not appropriate.

3. Boot-time WARN_ON() if CONFIG_RCU_USER_QS=y.

This seems to me to be a tad excessive. But the place to do it
might be rcu_bootup_announce_oddness() in kernel/rcutree_plugin.h.

4. Remove CONFIG_RCU_USER_QS from Kconfig, so that users have to
patch their kernel to enable it.

This also seems a tad excessive.

5. Maintain CONFIG_RCU_USER_QS out of tree, for example in the
-rt patchset.

This is a good place to start, but it has been where
CONFIG_RCU_USER_QS has been for some time, and although it
got some good testing, it clearly needs more. In my view,
CONFIG_RCU_USER_QS has outgrown its out-of-tree roots.

6. Boot-time add_taint() if CONFIG_RCU_USER_QS=y, as suggested
by Matthew Garrett. The taint value might be TAINT_CRAP,
TAINT_OOT_MODULE, TAINT_WARN, or TAINT_FIRMWARE_WORKAROUND --
all the other taint values disable lockdep. Of these four,
TAINT_OOT_MODULE and TAINT_FIRMWARE_WORKAROUND are clearly
off-topic, leaving TAINT_CRAP and TAINT_WARN. Taking them one
at a time:

TAINT_CRAP: Used when loading modules from staging.

TAINT_WARN: Used when "scheduling while atomic" is encountered.

So I have my tongue only halfway in my cheek when I suggest
starting with TAINT_CRAP, then moving to TAINT_WARN, then
removing the tainting altogether. The place to do this might
be rcu_bootup_announce_oddness() in kernel/rcutree_plugin.h.

So how about the following progression?

A. Early days, only a few crazies should test. In this case, the
code should be out of tree, perhaps in something like -rt,
perhaps as a set of patches.

B. Need more testers, but still not expected to work reasonably.
Mainline, but depending on CONFIG_BROKEN. (I am not all that
enthusiastic about this option, but am including it for
completeness.)

C. Need wide testing, but don't want 100,000,000 unsuspecting
test subjects. Taint the kernel with TAINT_CRAP.

D. OK for production in special situations, but definitely not
for typical users. Taint the kernel with TAINT_WARN.

E. Ready for general production use. Mainlined without restrictions.

I would say that CONFIG_RCU_USER_QS is currently at point C above, it
clearly now needs testing on a wide variety of hardware, but also is
clearly not ready for 100,000,000 users.

Thoughts?

Thanx, Paul

2012-10-06 16:10:38

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

2012/10/5 Paul E. McKenney <[email protected]>:
> On Thu, Oct 04, 2012 at 07:31:50AM -0700, Paul E. McKenney wrote:
>> On Thu, Oct 04, 2012 at 02:55:39AM +0100, Matthew Garrett wrote:
>> > On Wed, Oct 03, 2012 at 01:03:14PM -0700, Paul E. McKenney wrote:
>> >
>> > > That has not proven sufficient for me in the past, RCU_FAST_NO_HZ
>> > > being a case in point.
>> >
>> > Taint the kernel at boot time? That'd be sufficient to force distros to
>> > disable it.
>>
>> Cool! That does sound much more socially responsible than my thought
>> of forcing a splat (e.g., WARN_ON(1)) during boot. ;-)
>
> So, from what I can see, here is the list of the ways of warning distros
> off of a given kernel config option, taken in terms of CONFIG_RCU_USER_QS:
>
> 1. Make CONFIG_RCU_USER_QS depend on CONFIG_BROKEN.
>
> It sounds to me like distros would avoid adding this (do they?),
> but tester would probably avoid it as well.
>
> 2. Make CONFIG_RCU_USER_QS depend on CONFIG_STAGING.
>
> As Frederic noted, this is more of a driver thing than a
> core-kernel thing, so probably not appropriate.
>
> 3. Boot-time WARN_ON() if CONFIG_RCU_USER_QS=y.
>
> This seems to me to be a tad excessive. But the place to do it
> might be rcu_bootup_announce_oddness() in kernel/rcutree_plugin.h.
>
> 4. Remove CONFIG_RCU_USER_QS from Kconfig, so that users have to
> patch their kernel to enable it.
>
> This also seems a tad excessive.
>
> 5. Maintain CONFIG_RCU_USER_QS out of tree, for example in the
> -rt patchset.
>
> This is a good place to start, but it has been where
> CONFIG_RCU_USER_QS has been for some time, and although it
> got some good testing, it clearly needs more. In my view,
> CONFIG_RCU_USER_QS has outgrown its out-of-tree roots.
>
> 6. Boot-time add_taint() if CONFIG_RCU_USER_QS=y, as suggested
> by Matthew Garrett. The taint value might be TAINT_CRAP,
> TAINT_OOT_MODULE, TAINT_WARN, or TAINT_FIRMWARE_WORKAROUND --
> all the other taint values disable lockdep. Of these four,
> TAINT_OOT_MODULE and TAINT_FIRMWARE_WORKAROUND are clearly
> off-topic, leaving TAINT_CRAP and TAINT_WARN. Taking them one
> at a time:
>
> TAINT_CRAP: Used when loading modules from staging.
>
> TAINT_WARN: Used when "scheduling while atomic" is encountered.
>
> So I have my tongue only halfway in my cheek when I suggest
> starting with TAINT_CRAP, then moving to TAINT_WARN, then
> removing the tainting altogether. The place to do this might
> be rcu_bootup_announce_oddness() in kernel/rcutree_plugin.h.
>
> So how about the following progression?
>
> A. Early days, only a few crazies should test. In this case, the
> code should be out of tree, perhaps in something like -rt,
> perhaps as a set of patches.
>
> B. Need more testers, but still not expected to work reasonably.
> Mainline, but depending on CONFIG_BROKEN. (I am not all that
> enthusiastic about this option, but am including it for
> completeness.)

Yeah neither am I. With a dependency on CONFIG_BROKEN, it considerably
reduce the testing coverage too.

>
> C. Need wide testing, but don't want 100,000,000 unsuspecting
> test subjects. Taint the kernel with TAINT_CRAP.
>
> D. OK for production in special situations, but definitely not
> for typical users. Taint the kernel with TAINT_WARN.
>
> E. Ready for general production use. Mainlined without restrictions.
>
> I would say that CONFIG_RCU_USER_QS is currently at point C above, it
> clearly now needs testing on a wide variety of hardware, but also is
> clearly not ready for 100,000,000 users.
>
> Thoughts?

Really I would much prefer to add some "Don't enable it unless you're
doing kernel hacking.
If unsure say N" text in the Kconfig.

I can understand that distros want to cover as much feature as they
can for their users. But
should it be an excuse for not reading outstanding warnings in Kconfig
help text?

Or may be add some specific warning yeah. I wouldn't mind much.

2012-10-07 01:46:17

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Sat, Oct 06, 2012 at 06:10:36PM +0200, Frederic Weisbecker wrote:
> 2012/10/5 Paul E. McKenney <[email protected]>:
> > On Thu, Oct 04, 2012 at 07:31:50AM -0700, Paul E. McKenney wrote:
> >> On Thu, Oct 04, 2012 at 02:55:39AM +0100, Matthew Garrett wrote:
> >> > On Wed, Oct 03, 2012 at 01:03:14PM -0700, Paul E. McKenney wrote:
> >> >
> >> > > That has not proven sufficient for me in the past, RCU_FAST_NO_HZ
> >> > > being a case in point.
> >> >
> >> > Taint the kernel at boot time? That'd be sufficient to force distros to
> >> > disable it.
> >>
> >> Cool! That does sound much more socially responsible than my thought
> >> of forcing a splat (e.g., WARN_ON(1)) during boot. ;-)
> >
> > So, from what I can see, here is the list of the ways of warning distros
> > off of a given kernel config option, taken in terms of CONFIG_RCU_USER_QS:
> >
> > 1. Make CONFIG_RCU_USER_QS depend on CONFIG_BROKEN.
> >
> > It sounds to me like distros would avoid adding this (do they?),
> > but tester would probably avoid it as well.
> >
> > 2. Make CONFIG_RCU_USER_QS depend on CONFIG_STAGING.
> >
> > As Frederic noted, this is more of a driver thing than a
> > core-kernel thing, so probably not appropriate.
> >
> > 3. Boot-time WARN_ON() if CONFIG_RCU_USER_QS=y.
> >
> > This seems to me to be a tad excessive. But the place to do it
> > might be rcu_bootup_announce_oddness() in kernel/rcutree_plugin.h.
> >
> > 4. Remove CONFIG_RCU_USER_QS from Kconfig, so that users have to
> > patch their kernel to enable it.
> >
> > This also seems a tad excessive.
> >
> > 5. Maintain CONFIG_RCU_USER_QS out of tree, for example in the
> > -rt patchset.
> >
> > This is a good place to start, but it has been where
> > CONFIG_RCU_USER_QS has been for some time, and although it
> > got some good testing, it clearly needs more. In my view,
> > CONFIG_RCU_USER_QS has outgrown its out-of-tree roots.
> >
> > 6. Boot-time add_taint() if CONFIG_RCU_USER_QS=y, as suggested
> > by Matthew Garrett. The taint value might be TAINT_CRAP,
> > TAINT_OOT_MODULE, TAINT_WARN, or TAINT_FIRMWARE_WORKAROUND --
> > all the other taint values disable lockdep. Of these four,
> > TAINT_OOT_MODULE and TAINT_FIRMWARE_WORKAROUND are clearly
> > off-topic, leaving TAINT_CRAP and TAINT_WARN. Taking them one
> > at a time:
> >
> > TAINT_CRAP: Used when loading modules from staging.
> >
> > TAINT_WARN: Used when "scheduling while atomic" is encountered.
> >
> > So I have my tongue only halfway in my cheek when I suggest
> > starting with TAINT_CRAP, then moving to TAINT_WARN, then
> > removing the tainting altogether. The place to do this might
> > be rcu_bootup_announce_oddness() in kernel/rcutree_plugin.h.
> >
> > So how about the following progression?
> >
> > A. Early days, only a few crazies should test. In this case, the
> > code should be out of tree, perhaps in something like -rt,
> > perhaps as a set of patches.
> >
> > B. Need more testers, but still not expected to work reasonably.
> > Mainline, but depending on CONFIG_BROKEN. (I am not all that
> > enthusiastic about this option, but am including it for
> > completeness.)
>
> Yeah neither am I. With a dependency on CONFIG_BROKEN, it considerably
> reduce the testing coverage too.

;-)

> > C. Need wide testing, but don't want 100,000,000 unsuspecting
> > test subjects. Taint the kernel with TAINT_CRAP.
> >
> > D. OK for production in special situations, but definitely not
> > for typical users. Taint the kernel with TAINT_WARN.
> >
> > E. Ready for general production use. Mainlined without restrictions.
> >
> > I would say that CONFIG_RCU_USER_QS is currently at point C above, it
> > clearly now needs testing on a wide variety of hardware, but also is
> > clearly not ready for 100,000,000 users.
> >
> > Thoughts?
>
> Really I would much prefer to add some "Don't enable it unless you're
> doing kernel hacking.
> If unsure say N" text in the Kconfig.
>
> I can understand that distros want to cover as much feature as they
> can for their users. But
> should it be an excuse for not reading outstanding warnings in Kconfig
> help text?

In my experience, they do not read these warnings carefully. :-(
Or perhaps they do read them, but react to them by running the code
through some test suite rather than by putting full faith in the
warning.

> Or may be add some specific warning yeah. I wouldn't mind much.

We have some weeks to think about it -- I cannot see pushing a
warning in as a regression. ;-)

Thanx, Paul

2012-10-07 02:33:50

by Dave Airlie

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

>>
>> Really I would much prefer to add some "Don't enable it unless you're
>> doing kernel hacking.
>> If unsure say N" text in the Kconfig.
>>
>> I can understand that distros want to cover as much feature as they
>> can for their users. But
>> should it be an excuse for not reading outstanding warnings in Kconfig
>> help text?
>
> In my experience, they do not read these warnings carefully. :-(
> Or perhaps they do read them, but react to them by running the code
> through some test suite rather than by putting full faith in the
> warning.
>

I think Kconfig is mostly what distro would like to use the thing is
the Kconfig text needs to be there upfront when its merged, not two
months later, since then it too late for a distro to notice.

I'd bet most distros would read the warnings, but in a lot of cases
the warning don't exist until its too late.

Dave.

>> Or may be add some specific warning yeah. I wouldn't mind much.
>
> We have some weeks to think about it -- I cannot see pushing a
> warning in as a regression. ;-)
>
> Thanx, Paul
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2012-10-07 16:30:46

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Sun, Oct 07, 2012 at 12:33:48PM +1000, Dave Airlie wrote:
> >>
> >> Really I would much prefer to add some "Don't enable it unless you're
> >> doing kernel hacking.
> >> If unsure say N" text in the Kconfig.
> >>
> >> I can understand that distros want to cover as much feature as they
> >> can for their users. But
> >> should it be an excuse for not reading outstanding warnings in Kconfig
> >> help text?
> >
> > In my experience, they do not read these warnings carefully. :-(
> > Or perhaps they do read them, but react to them by running the code
> > through some test suite rather than by putting full faith in the
> > warning.
>
> I think Kconfig is mostly what distro would like to use the thing is
> the Kconfig text needs to be there upfront when its merged, not two
> months later, since then it too late for a distro to notice.
>
> I'd bet most distros would read the warnings, but in a lot of cases
> the warning don't exist until its too late.

In the case of CONFIG_RCU_USER_QS you are quite right, the warning
should have been there from the beginning and was not. I suppose you
could argue that the warning was not sufficiently harsh in the case of
CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:

config RCU_FAST_NO_HZ
bool "Accelerate last non-dyntick-idle CPU's grace periods"
depends on TREE_RCU && NO_HZ && SMP
default n
help
This option causes RCU to attempt to accelerate grace periods
in order to allow the final CPU to enter dynticks-idle state
more quickly. On the other hand, this option increases the
overhead of the dynticks-idle checking, particularly on systems
with large numbers of CPUs.

Say Y if energy efficiency is critically important, particularly
if you have relatively few CPUs.

Say N if you are unsure.

I have since made RCU_FAST_NO_HZ more generally applicable, so it is
OK to enable now. I suppose I need to update the help text...

Either way, however, it would be good to tag an experimental config
option at boot time. Even if the help text gives very clear warnings,
it would be good to have the option defend itself against the occasional
inevitable typo.

Thanx, Paul

> Dave.
>
>
> >> Or may be add some specific warning yeah. I wouldn't mind much.
> >
> > We have some weeks to think about it -- I cannot see pushing a
> > warning in as a regression. ;-)
> >
> > Thanx, Paul
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>

2012-10-07 20:19:19

by Dave Jones

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote:

> > I think Kconfig is mostly what distro would like to use the thing is
> > the Kconfig text needs to be there upfront when its merged, not two
> > months later, since then it too late for a distro to notice.
> >
> > I'd bet most distros would read the warnings, but in a lot of cases
> > the warning don't exist until its too late.
>
> In the case of CONFIG_RCU_USER_QS you are quite right, the warning
> should have been there from the beginning and was not. I suppose you
> could argue that the warning was not sufficiently harsh in the case of
> CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:

Maybe if we had a universally agreed upon tag for kconfig, like
"distro recommendation: N" that would make things obvious, and also allow
those of us unfortunate enough to maintain distro kernels to have something
to easily grep for. This would also catch the case when you eventually (hopefully)
flip from an N to a Y.

There will likely still be some distros that will decide they know better
(and I'm pretty sure eventually I'll find reason to do so myself), but it at least
gives the feature maintainer the "I told you so" clause.

Something we do quite often for our in-development kernels is enable something
that's shiny, new and unproven, and then when we branch for a release, we turn
it back off. It would be great if a lot of this kind of thing could be more automated.

Dave

2012-10-08 01:04:56

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Sun, Oct 07, 2012 at 04:18:54PM -0400, Dave Jones wrote:
> On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote:
>
> > > I think Kconfig is mostly what distro would like to use the thing is
> > > the Kconfig text needs to be there upfront when its merged, not two
> > > months later, since then it too late for a distro to notice.
> > >
> > > I'd bet most distros would read the warnings, but in a lot of cases
> > > the warning don't exist until its too late.
> >
> > In the case of CONFIG_RCU_USER_QS you are quite right, the warning
> > should have been there from the beginning and was not. I suppose you
> > could argue that the warning was not sufficiently harsh in the case of
> > CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:
>
> Maybe if we had a universally agreed upon tag for kconfig, like
> "distro recommendation: N" that would make things obvious, and also allow
> those of us unfortunate enough to maintain distro kernels to have something
> to easily grep for. This would also catch the case when you eventually (hopefully)
> flip from an N to a Y.
>
> There will likely still be some distros that will decide they know better
> (and I'm pretty sure eventually I'll find reason to do so myself), but it at least
> gives the feature maintainer the "I told you so" clause.
>
> Something we do quite often for our in-development kernels is enable something
> that's shiny, new and unproven, and then when we branch for a release, we turn
> it back off. It would be great if a lot of this kind of thing could be more automated.

One approach would be to have CONFIG_DISTRO, so that experimental
features could use "depends on !DISTRO", but also to have multiple
"BLEEDING" symbols. For example, given a CONFIG_DISTRO_BLEEDING_HPC
and CONFIG_DISTRO_BLEEDING_RT, CONFIG_RCU_USER_QS might eventually
use the following clause:

depends on !DISTRO || DISTRO_BLEEDING_HPC || DISTRO_BLEEDING_RT

A normal distro would define DISTRO, a distro looking to provide bleeding-edge
HPC or real-time features would also define DISTRO_BLEEDING_HPC or
DISTRO_BLEEDING_RT, respectively.

Does that make sense, or am I being overly naive?

Thanx, Paul

2012-10-08 22:07:29

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Sun, Oct 7, 2012 at 6:04 PM, Paul E. McKenney
<[email protected]> wrote:
> On Sun, Oct 07, 2012 at 04:18:54PM -0400, Dave Jones wrote:
>> On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote:
>>
>> > > I think Kconfig is mostly what distro would like to use the thing is
>> > > the Kconfig text needs to be there upfront when its merged, not two
>> > > months later, since then it too late for a distro to notice.
>> > >
>> > > I'd bet most distros would read the warnings, but in a lot of cases
>> > > the warning don't exist until its too late.
>> >
>> > In the case of CONFIG_RCU_USER_QS you are quite right, the warning
>> > should have been there from the beginning and was not. I suppose you
>> > could argue that the warning was not sufficiently harsh in the case of
>> > CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:
>>
>> Maybe if we had a universally agreed upon tag for kconfig, like
>> "distro recommendation: N" that would make things obvious, and also allow
>> those of us unfortunate enough to maintain distro kernels to have something
>> to easily grep for. This would also catch the case when you eventually (hopefully)
>> flip from an N to a Y.
>>
>> There will likely still be some distros that will decide they know better
>> (and I'm pretty sure eventually I'll find reason to do so myself), but it at least
>> gives the feature maintainer the "I told you so" clause.
>>
>> Something we do quite often for our in-development kernels is enable something
>> that's shiny, new and unproven, and then when we branch for a release, we turn
>> it back off. It would be great if a lot of this kind of thing could be more automated.
>
> One approach would be to have CONFIG_DISTRO, so that experimental
> features could use "depends on !DISTRO", but also to have multiple
> "BLEEDING" symbols. For example, given a CONFIG_DISTRO_BLEEDING_HPC
> and CONFIG_DISTRO_BLEEDING_RT, CONFIG_RCU_USER_QS might eventually
> use the following clause:
>
> depends on !DISTRO || DISTRO_BLEEDING_HPC || DISTRO_BLEEDING_RT
>
> A normal distro would define DISTRO, a distro looking to provide bleeding-edge
> HPC or real-time features would also define DISTRO_BLEEDING_HPC or
> DISTRO_BLEEDING_RT, respectively.
>
> Does that make sense, or am I being overly naive?

I think we should avoid any global configs that disable things. We'll
just end up in the same place with distros again.

-Kees

--
Kees Cook
Chrome OS Security

2012-10-08 22:08:45

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Wed, Oct 3, 2012 at 9:17 AM, Greg Kroah-Hartman
<[email protected]> 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 <[email protected]>
>> > CC: "Eric W. Biederman" <[email protected]>
>> > CC: Serge Hallyn <[email protected]>
>> > CC: "Paul E. McKenney" <[email protected]>
>> > CC: Andrew Morton <[email protected]>
>> > CC: Frederic Weisbecker <[email protected]>
>> > Signed-off-by: Kees Cook <[email protected]>
>> > ---
>> >
>> > 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 :)

So, should I update the commit description to include a suggested
alternative? (If so, which one?)

Who is going to carry this initial patch, btw?

-Kees

--
Kees Cook
Chrome OS Security

2012-10-08 22:30:19

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 08, 2012 at 03:07:24PM -0700, Kees Cook wrote:
> On Sun, Oct 7, 2012 at 6:04 PM, Paul E. McKenney
> <[email protected]> wrote:
> > On Sun, Oct 07, 2012 at 04:18:54PM -0400, Dave Jones wrote:
> >> On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote:
> >>
> >> > > I think Kconfig is mostly what distro would like to use the thing is
> >> > > the Kconfig text needs to be there upfront when its merged, not two
> >> > > months later, since then it too late for a distro to notice.
> >> > >
> >> > > I'd bet most distros would read the warnings, but in a lot of cases
> >> > > the warning don't exist until its too late.
> >> >
> >> > In the case of CONFIG_RCU_USER_QS you are quite right, the warning
> >> > should have been there from the beginning and was not. I suppose you
> >> > could argue that the warning was not sufficiently harsh in the case of
> >> > CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:
> >>
> >> Maybe if we had a universally agreed upon tag for kconfig, like
> >> "distro recommendation: N" that would make things obvious, and also allow
> >> those of us unfortunate enough to maintain distro kernels to have something
> >> to easily grep for. This would also catch the case when you eventually (hopefully)
> >> flip from an N to a Y.
> >>
> >> There will likely still be some distros that will decide they know better
> >> (and I'm pretty sure eventually I'll find reason to do so myself), but it at least
> >> gives the feature maintainer the "I told you so" clause.
> >>
> >> Something we do quite often for our in-development kernels is enable something
> >> that's shiny, new and unproven, and then when we branch for a release, we turn
> >> it back off. It would be great if a lot of this kind of thing could be more automated.
> >
> > One approach would be to have CONFIG_DISTRO, so that experimental
> > features could use "depends on !DISTRO", but also to have multiple
> > "BLEEDING" symbols. For example, given a CONFIG_DISTRO_BLEEDING_HPC
> > and CONFIG_DISTRO_BLEEDING_RT, CONFIG_RCU_USER_QS might eventually
> > use the following clause:
> >
> > depends on !DISTRO || DISTRO_BLEEDING_HPC || DISTRO_BLEEDING_RT
> >
> > A normal distro would define DISTRO, a distro looking to provide bleeding-edge
> > HPC or real-time features would also define DISTRO_BLEEDING_HPC or
> > DISTRO_BLEEDING_RT, respectively.
> >
> > Does that make sense, or am I being overly naive?
>
> I think we should avoid any global configs that disable things. We'll
> just end up in the same place with distros again.

So you believe that we should taint the kernel or splat on boot to
warn distros off of features that might not be ready for 100 million
users? Or do you have some other approach in mind?

Thanx, Paul

2012-10-08 22:37:56

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 8, 2012 at 3:29 PM, Paul E. McKenney
<[email protected]> wrote:
> On Mon, Oct 08, 2012 at 03:07:24PM -0700, Kees Cook wrote:
>> On Sun, Oct 7, 2012 at 6:04 PM, Paul E. McKenney
>> <[email protected]> wrote:
>> > On Sun, Oct 07, 2012 at 04:18:54PM -0400, Dave Jones wrote:
>> >> On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote:
>> >>
>> >> > > I think Kconfig is mostly what distro would like to use the thing is
>> >> > > the Kconfig text needs to be there upfront when its merged, not two
>> >> > > months later, since then it too late for a distro to notice.
>> >> > >
>> >> > > I'd bet most distros would read the warnings, but in a lot of cases
>> >> > > the warning don't exist until its too late.
>> >> >
>> >> > In the case of CONFIG_RCU_USER_QS you are quite right, the warning
>> >> > should have been there from the beginning and was not. I suppose you
>> >> > could argue that the warning was not sufficiently harsh in the case of
>> >> > CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:
>> >>
>> >> Maybe if we had a universally agreed upon tag for kconfig, like
>> >> "distro recommendation: N" that would make things obvious, and also allow
>> >> those of us unfortunate enough to maintain distro kernels to have something
>> >> to easily grep for. This would also catch the case when you eventually (hopefully)
>> >> flip from an N to a Y.
>> >>
>> >> There will likely still be some distros that will decide they know better
>> >> (and I'm pretty sure eventually I'll find reason to do so myself), but it at least
>> >> gives the feature maintainer the "I told you so" clause.
>> >>
>> >> Something we do quite often for our in-development kernels is enable something
>> >> that's shiny, new and unproven, and then when we branch for a release, we turn
>> >> it back off. It would be great if a lot of this kind of thing could be more automated.
>> >
>> > One approach would be to have CONFIG_DISTRO, so that experimental
>> > features could use "depends on !DISTRO", but also to have multiple
>> > "BLEEDING" symbols. For example, given a CONFIG_DISTRO_BLEEDING_HPC
>> > and CONFIG_DISTRO_BLEEDING_RT, CONFIG_RCU_USER_QS might eventually
>> > use the following clause:
>> >
>> > depends on !DISTRO || DISTRO_BLEEDING_HPC || DISTRO_BLEEDING_RT
>> >
>> > A normal distro would define DISTRO, a distro looking to provide bleeding-edge
>> > HPC or real-time features would also define DISTRO_BLEEDING_HPC or
>> > DISTRO_BLEEDING_RT, respectively.
>> >
>> > Does that make sense, or am I being overly naive?
>>
>> I think we should avoid any global configs that disable things. We'll
>> just end up in the same place with distros again.
>
> So you believe that we should taint the kernel or splat on boot to
> warn distros off of features that might not be ready for 100 million
> users? Or do you have some other approach in mind?

Personally, I think taint+printk seems like the right way to go.

-Kees

--
Kees Cook
Chrome OS Security

2012-10-08 22:41:04

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 8, 2012 at 3:37 PM, Kees Cook <[email protected]> wrote:
> On Mon, Oct 8, 2012 at 3:29 PM, Paul E. McKenney
> <[email protected]> wrote:
>> On Mon, Oct 08, 2012 at 03:07:24PM -0700, Kees Cook wrote:
>>> On Sun, Oct 7, 2012 at 6:04 PM, Paul E. McKenney
>>> <[email protected]> wrote:
>>> > On Sun, Oct 07, 2012 at 04:18:54PM -0400, Dave Jones wrote:
>>> >> On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote:
>>> >>
>>> >> > > I think Kconfig is mostly what distro would like to use the thing is
>>> >> > > the Kconfig text needs to be there upfront when its merged, not two
>>> >> > > months later, since then it too late for a distro to notice.
>>> >> > >
>>> >> > > I'd bet most distros would read the warnings, but in a lot of cases
>>> >> > > the warning don't exist until its too late.
>>> >> >
>>> >> > In the case of CONFIG_RCU_USER_QS you are quite right, the warning
>>> >> > should have been there from the beginning and was not. I suppose you
>>> >> > could argue that the warning was not sufficiently harsh in the case of
>>> >> > CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:
>>> >>
>>> >> Maybe if we had a universally agreed upon tag for kconfig, like
>>> >> "distro recommendation: N" that would make things obvious, and also allow
>>> >> those of us unfortunate enough to maintain distro kernels to have something
>>> >> to easily grep for. This would also catch the case when you eventually (hopefully)
>>> >> flip from an N to a Y.
>>> >>
>>> >> There will likely still be some distros that will decide they know better
>>> >> (and I'm pretty sure eventually I'll find reason to do so myself), but it at least
>>> >> gives the feature maintainer the "I told you so" clause.
>>> >>
>>> >> Something we do quite often for our in-development kernels is enable something
>>> >> that's shiny, new and unproven, and then when we branch for a release, we turn
>>> >> it back off. It would be great if a lot of this kind of thing could be more automated.
>>> >
>>> > One approach would be to have CONFIG_DISTRO, so that experimental
>>> > features could use "depends on !DISTRO", but also to have multiple
>>> > "BLEEDING" symbols. For example, given a CONFIG_DISTRO_BLEEDING_HPC
>>> > and CONFIG_DISTRO_BLEEDING_RT, CONFIG_RCU_USER_QS might eventually
>>> > use the following clause:
>>> >
>>> > depends on !DISTRO || DISTRO_BLEEDING_HPC || DISTRO_BLEEDING_RT
>>> >
>>> > A normal distro would define DISTRO, a distro looking to provide bleeding-edge
>>> > HPC or real-time features would also define DISTRO_BLEEDING_HPC or
>>> > DISTRO_BLEEDING_RT, respectively.
>>> >
>>> > Does that make sense, or am I being overly naive?
>>>
>>> I think we should avoid any global configs that disable things. We'll
>>> just end up in the same place with distros again.
>>
>> So you believe that we should taint the kernel or splat on boot to
>> warn distros off of features that might not be ready for 100 million
>> users? Or do you have some other approach in mind?
>
> Personally, I think taint+printk seems like the right way to go.

Actually, I think printk is sufficient. I don't want kernel taint to
become the new CONFIG_EXPERIMENTAL. :)

-Kees

--
Kees Cook
Chrome OS Security

2012-10-08 23:00:01

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 08, 2012 at 03:40:57PM -0700, Kees Cook wrote:
> On Mon, Oct 8, 2012 at 3:37 PM, Kees Cook <[email protected]> wrote:
> > On Mon, Oct 8, 2012 at 3:29 PM, Paul E. McKenney
> > <[email protected]> wrote:
> >> On Mon, Oct 08, 2012 at 03:07:24PM -0700, Kees Cook wrote:
> >>> On Sun, Oct 7, 2012 at 6:04 PM, Paul E. McKenney
> >>> <[email protected]> wrote:
> >>> > On Sun, Oct 07, 2012 at 04:18:54PM -0400, Dave Jones wrote:
> >>> >> On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote:
> >>> >>
> >>> >> > > I think Kconfig is mostly what distro would like to use the thing is
> >>> >> > > the Kconfig text needs to be there upfront when its merged, not two
> >>> >> > > months later, since then it too late for a distro to notice.
> >>> >> > >
> >>> >> > > I'd bet most distros would read the warnings, but in a lot of cases
> >>> >> > > the warning don't exist until its too late.
> >>> >> >
> >>> >> > In the case of CONFIG_RCU_USER_QS you are quite right, the warning
> >>> >> > should have been there from the beginning and was not. I suppose you
> >>> >> > could argue that the warning was not sufficiently harsh in the case of
> >>> >> > CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:
> >>> >>
> >>> >> Maybe if we had a universally agreed upon tag for kconfig, like
> >>> >> "distro recommendation: N" that would make things obvious, and also allow
> >>> >> those of us unfortunate enough to maintain distro kernels to have something
> >>> >> to easily grep for. This would also catch the case when you eventually (hopefully)
> >>> >> flip from an N to a Y.
> >>> >>
> >>> >> There will likely still be some distros that will decide they know better
> >>> >> (and I'm pretty sure eventually I'll find reason to do so myself), but it at least
> >>> >> gives the feature maintainer the "I told you so" clause.
> >>> >>
> >>> >> Something we do quite often for our in-development kernels is enable something
> >>> >> that's shiny, new and unproven, and then when we branch for a release, we turn
> >>> >> it back off. It would be great if a lot of this kind of thing could be more automated.
> >>> >
> >>> > One approach would be to have CONFIG_DISTRO, so that experimental
> >>> > features could use "depends on !DISTRO", but also to have multiple
> >>> > "BLEEDING" symbols. For example, given a CONFIG_DISTRO_BLEEDING_HPC
> >>> > and CONFIG_DISTRO_BLEEDING_RT, CONFIG_RCU_USER_QS might eventually
> >>> > use the following clause:
> >>> >
> >>> > depends on !DISTRO || DISTRO_BLEEDING_HPC || DISTRO_BLEEDING_RT
> >>> >
> >>> > A normal distro would define DISTRO, a distro looking to provide bleeding-edge
> >>> > HPC or real-time features would also define DISTRO_BLEEDING_HPC or
> >>> > DISTRO_BLEEDING_RT, respectively.
> >>> >
> >>> > Does that make sense, or am I being overly naive?
> >>>
> >>> I think we should avoid any global configs that disable things. We'll
> >>> just end up in the same place with distros again.
> >>
> >> So you believe that we should taint the kernel or splat on boot to
> >> warn distros off of features that might not be ready for 100 million
> >> users? Or do you have some other approach in mind?
> >
> > Personally, I think taint+printk seems like the right way to go.
>
> Actually, I think printk is sufficient. I don't want kernel taint to
> become the new CONFIG_EXPERIMENTAL. :)

OK, I'll bite...

Why would kernel taint be more likely to become the new CONFIG_EXPERIMENTAL
than printk() would?

Thanx, Paul

2012-10-08 23:23:41

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 8, 2012 at 3:59 PM, Paul E. McKenney
<[email protected]> wrote:
> On Mon, Oct 08, 2012 at 03:40:57PM -0700, Kees Cook wrote:
>> On Mon, Oct 8, 2012 at 3:37 PM, Kees Cook <[email protected]> wrote:
>> > On Mon, Oct 8, 2012 at 3:29 PM, Paul E. McKenney
>> > <[email protected]> wrote:
>> >> On Mon, Oct 08, 2012 at 03:07:24PM -0700, Kees Cook wrote:
>> >>> On Sun, Oct 7, 2012 at 6:04 PM, Paul E. McKenney
>> >>> <[email protected]> wrote:
>> >>> > On Sun, Oct 07, 2012 at 04:18:54PM -0400, Dave Jones wrote:
>> >>> >> On Sun, Oct 07, 2012 at 09:30:29AM -0700, Paul E. McKenney wrote:
>> >>> >>
>> >>> >> > > I think Kconfig is mostly what distro would like to use the thing is
>> >>> >> > > the Kconfig text needs to be there upfront when its merged, not two
>> >>> >> > > months later, since then it too late for a distro to notice.
>> >>> >> > >
>> >>> >> > > I'd bet most distros would read the warnings, but in a lot of cases
>> >>> >> > > the warning don't exist until its too late.
>> >>> >> >
>> >>> >> > In the case of CONFIG_RCU_USER_QS you are quite right, the warning
>> >>> >> > should have been there from the beginning and was not. I suppose you
>> >>> >> > could argue that the warning was not sufficiently harsh in the case of
>> >>> >> > CONFIG_RCU_FAST_NO_HZ, but either way it did get ignored:
>> >>> >>
>> >>> >> Maybe if we had a universally agreed upon tag for kconfig, like
>> >>> >> "distro recommendation: N" that would make things obvious, and also allow
>> >>> >> those of us unfortunate enough to maintain distro kernels to have something
>> >>> >> to easily grep for. This would also catch the case when you eventually (hopefully)
>> >>> >> flip from an N to a Y.
>> >>> >>
>> >>> >> There will likely still be some distros that will decide they know better
>> >>> >> (and I'm pretty sure eventually I'll find reason to do so myself), but it at least
>> >>> >> gives the feature maintainer the "I told you so" clause.
>> >>> >>
>> >>> >> Something we do quite often for our in-development kernels is enable something
>> >>> >> that's shiny, new and unproven, and then when we branch for a release, we turn
>> >>> >> it back off. It would be great if a lot of this kind of thing could be more automated.
>> >>> >
>> >>> > One approach would be to have CONFIG_DISTRO, so that experimental
>> >>> > features could use "depends on !DISTRO", but also to have multiple
>> >>> > "BLEEDING" symbols. For example, given a CONFIG_DISTRO_BLEEDING_HPC
>> >>> > and CONFIG_DISTRO_BLEEDING_RT, CONFIG_RCU_USER_QS might eventually
>> >>> > use the following clause:
>> >>> >
>> >>> > depends on !DISTRO || DISTRO_BLEEDING_HPC || DISTRO_BLEEDING_RT
>> >>> >
>> >>> > A normal distro would define DISTRO, a distro looking to provide bleeding-edge
>> >>> > HPC or real-time features would also define DISTRO_BLEEDING_HPC or
>> >>> > DISTRO_BLEEDING_RT, respectively.
>> >>> >
>> >>> > Does that make sense, or am I being overly naive?
>> >>>
>> >>> I think we should avoid any global configs that disable things. We'll
>> >>> just end up in the same place with distros again.
>> >>
>> >> So you believe that we should taint the kernel or splat on boot to
>> >> warn distros off of features that might not be ready for 100 million
>> >> users? Or do you have some other approach in mind?
>> >
>> > Personally, I think taint+printk seems like the right way to go.
>>
>> Actually, I think printk is sufficient. I don't want kernel taint to
>> become the new CONFIG_EXPERIMENTAL. :)
>
> OK, I'll bite...
>
> Why would kernel taint be more likely to become the new CONFIG_EXPERIMENTAL
> than printk() would?

I was imagining the case where distros were still turning lots of
stuff on, and they wanted a genuinely experimental thing anyway, then
they'd end up with all their kernels tainted. A printk is easier to
"live with", where as taint wouldn't be, I think.

-Kees

--
Kees Cook
Chrome OS Security

2012-10-08 23:54:03

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 08, 2012 at 03:08:40PM -0700, Kees Cook wrote:
> On Wed, Oct 3, 2012 at 9:17 AM, Greg Kroah-Hartman
> <[email protected]> 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 <[email protected]>
> >> > CC: "Eric W. Biederman" <[email protected]>
> >> > CC: Serge Hallyn <[email protected]>
> >> > CC: "Paul E. McKenney" <[email protected]>
> >> > CC: Andrew Morton <[email protected]>
> >> > CC: Frederic Weisbecker <[email protected]>
> >> > Signed-off-by: Kees Cook <[email protected]>
> >> > ---
> >> >
> >> > 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 :)
>
> So, should I update the commit description to include a suggested
> alternative? (If so, which one?)

Which do you prefer?

> Who is going to carry this initial patch, btw?

You? :)

greg k-h

2012-10-09 00:46:13

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 8, 2012 at 4:53 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Mon, Oct 08, 2012 at 03:08:40PM -0700, Kees Cook wrote:
>> On Wed, Oct 3, 2012 at 9:17 AM, Greg Kroah-Hartman
>> <[email protected]> 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 <[email protected]>
>> >> > CC: "Eric W. Biederman" <[email protected]>
>> >> > CC: Serge Hallyn <[email protected]>
>> >> > CC: "Paul E. McKenney" <[email protected]>
>> >> > CC: Andrew Morton <[email protected]>
>> >> > CC: Frederic Weisbecker <[email protected]>
>> >> > Signed-off-by: Kees Cook <[email protected]>
>> >> > ---
>> >> >
>> >> > 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 :)
>>
>> So, should I update the commit description to include a suggested
>> alternative? (If so, which one?)
>
> Which do you prefer?

I think developers that want something harder that strongly worded
text in the Kconfig title or description should throw a printk.

>> Who is going to carry this initial patch, btw?
>
> You? :)

Do you mean to say I should ask Stephen to pull from one of my trees
for linux-next? If so, I've made this now:

git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git linux-next

-Kees

--
Kees Cook
Chrome OS Security

2012-10-09 01:21:02

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 08, 2012 at 05:46:08PM -0700, Kees Cook wrote:
> >> Who is going to carry this initial patch, btw?
> >
> > You? :)
>
> Do you mean to say I should ask Stephen to pull from one of my trees
> for linux-next? If so, I've made this now:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git linux-next

Sounds good to me, good luck.

greg k-h

2012-10-09 01:26:26

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 08, 2012 at 05:46:08PM -0700, Kees Cook wrote:
> On Mon, Oct 8, 2012 at 4:53 PM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Mon, Oct 08, 2012 at 03:08:40PM -0700, Kees Cook wrote:
> >> On Wed, Oct 3, 2012 at 9:17 AM, Greg Kroah-Hartman
> >> <[email protected]> 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 <[email protected]>
> >> >> > CC: "Eric W. Biederman" <[email protected]>
> >> >> > CC: Serge Hallyn <[email protected]>
> >> >> > CC: "Paul E. McKenney" <[email protected]>
> >> >> > CC: Andrew Morton <[email protected]>
> >> >> > CC: Frederic Weisbecker <[email protected]>
> >> >> > Signed-off-by: Kees Cook <[email protected]>
> >> >> > ---
> >> >> >
> >> >> > 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 :)
> >>
> >> So, should I update the commit description to include a suggested
> >> alternative? (If so, which one?)
> >
> > Which do you prefer?
>
> I think developers that want something harder that strongly worded
> text in the Kconfig title or description should throw a printk.

But having agreed-upon wording in the Kconfig title or description
is still goodness. Those of us who want printk()s, add_taint()s,
or even WARN_ON()s can always add them.

Thanx, Paul

> >> Who is going to carry this initial patch, btw?
> >
> > You? :)
>
> Do you mean to say I should ask Stephen to pull from one of my trees
> for linux-next? If so, I've made this now:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git linux-next
>
> -Kees
>
> --
> Kees Cook
> Chrome OS Security
>

2012-10-09 01:57:56

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

On Mon, Oct 8, 2012 at 6:26 PM, Paul E. McKenney
<[email protected]> wrote:
> On Mon, Oct 08, 2012 at 05:46:08PM -0700, Kees Cook wrote:
>> On Mon, Oct 8, 2012 at 4:53 PM, Greg Kroah-Hartman
>> <[email protected]> wrote:
>> > On Mon, Oct 08, 2012 at 03:08:40PM -0700, Kees Cook wrote:
>> >> On Wed, Oct 3, 2012 at 9:17 AM, Greg Kroah-Hartman
>> >> <[email protected]> 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 <[email protected]>
>> >> >> > CC: "Eric W. Biederman" <[email protected]>
>> >> >> > CC: Serge Hallyn <[email protected]>
>> >> >> > CC: "Paul E. McKenney" <[email protected]>
>> >> >> > CC: Andrew Morton <[email protected]>
>> >> >> > CC: Frederic Weisbecker <[email protected]>
>> >> >> > Signed-off-by: Kees Cook <[email protected]>
>> >> >> > ---
>> >> >> >
>> >> >> > 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 :)
>> >>
>> >> So, should I update the commit description to include a suggested
>> >> alternative? (If so, which one?)
>> >
>> > Which do you prefer?
>>
>> I think developers that want something harder that strongly worded
>> text in the Kconfig title or description should throw a printk.
>
> But having agreed-upon wording in the Kconfig title or description
> is still goodness. Those of us who want printk()s, add_taint()s,
> or even WARN_ON()s can always add them.

I agree. I think, actually, it might make sense to retain the
"(EXPERIMENTAL)" text in the title. This is what has already been done
for some of the other subsystems.

On Mon, Oct 8, 2012 at 6:20 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Mon, Oct 08, 2012 at 05:46:08PM -0700, Kees Cook wrote:
>> On Mon, Oct 8, 2012 at 4:53 PM, Greg Kroah-Hartman
>> <[email protected]> wrote:
>> > On Mon, Oct 08, 2012 at 03:08:40PM -0700, Kees Cook wrote:
>> >> Who is going to carry this initial patch, btw?
>> >
>> > You? :)
>>
>> Do you mean to say I should ask Stephen to pull from one of my trees
>> for linux-next? If so, I've made this now:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git linux-next
>
> Sounds good to me, good luck.

Stephen, can you add this tree to your pulls for linux-next?

Thanks!

-Kees

--
Kees Cook
Chrome OS Security

2012-10-09 02:47:51

by Stephen Rothwell

[permalink] [raw]

Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

Hi Kees,

On Mon, 8 Oct 2012 18:57:51 -0700 Kees Cook <[email protected]> wrote:
>
> On Mon, Oct 8, 2012 at 6:20 PM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Mon, Oct 08, 2012 at 05:46:08PM -0700, Kees Cook wrote:
> >> On Mon, Oct 8, 2012 at 4:53 PM, Greg Kroah-Hartman
> >> <[email protected]> wrote:
> >> > On Mon, Oct 08, 2012 at 03:08:40PM -0700, Kees Cook wrote:
> >> >> Who is going to carry this initial patch, btw?
> >> >
> >> > You? :)
> >>
> >> Do you mean to say I should ask Stephen to pull from one of my trees
> >> for linux-next? If so, I've made this now:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git linux-next
> >
> > Sounds good to me, good luck.
>
> Stephen, can you add this tree to your pulls for linux-next?

For this single commit, if you want it to go in during this merge window,
I suggest you send it as a patch to Linus. If there is going to be
ongoing work on this topic, then I will be happy to add your tree after
v3.7-rc1 is released (since the further work should be destined for v3.8,
right?).

--
Cheers,
Stephen Rothwell [email protected]

Attachments:

(No filename) (1.14 kB)
(No filename) (836.00 B)
Download all attachments

2012-10-09 06:01:37