linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Dave Airlie <airlied@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Kees Cook <keescook@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default
Date: Sun, 7 Oct 2012 16:18:54 -0400	[thread overview]
Message-ID: <20121007201854.GA6628@redhat.com> (raw)
In-Reply-To: <20121007163029.GG2485@linux.vnet.ibm.com>

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


  reply	other threads:[~2012-10-07 20:19 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02 19:50 [PATCH] make CONFIG_EXPERIMENTAL invisible and default Kees Cook
2012-10-02 21:40 ` Serge E. Hallyn
2012-10-03 13:25 ` Paul E. McKenney
2012-10-03 16:15   ` Kees Cook
2012-10-03 16:43     ` Josh Boyer
2012-10-03 16:16   ` Serge Hallyn
2012-10-03 16:17   ` Greg Kroah-Hartman
2012-10-03 16:47     ` Paul E. McKenney
2012-10-03 17:21       ` Greg Kroah-Hartman
2012-10-03 17:46         ` Frederic Weisbecker
2012-10-03 18:23           ` Josh Boyer
2012-10-03 19:36           ` Dave Jones
2012-10-03 20:05             ` Paul E. McKenney
2012-10-03 21:43             ` Frederic Weisbecker
2012-10-04 14:31               ` Paul E. McKenney
2012-10-03 17:46         ` Paul E. McKenney
2012-10-03 18:02           ` Serge Hallyn
2012-10-03 18:43       ` Kees Cook
2012-10-03 19:07         ` david
2012-10-03 20:03         ` Paul E. McKenney
2012-10-03 22:23           ` Eric W. Biederman
2012-10-04  0:11             ` Paul E. McKenney
2012-10-04  1:55           ` Matthew Garrett
2012-10-04 14:31             ` Paul E. McKenney
2012-10-05 16:46               ` Paul E. McKenney
2012-10-06 16:10                 ` Frederic Weisbecker
2012-10-07  1:44                   ` Paul E. McKenney
2012-10-07  2:33                     ` Dave Airlie
2012-10-07 16:30                       ` Paul E. McKenney
2012-10-07 20:18                         ` Dave Jones [this message]
2012-10-08  1:04                           ` Paul E. McKenney
2012-10-08 22:07                             ` Kees Cook
2012-10-08 22:29                               ` Paul E. McKenney
2012-10-08 22:37                                 ` Kees Cook
2012-10-08 22:40                                   ` Kees Cook
2012-10-08 22:59                                     ` Paul E. McKenney
2012-10-08 23:23                                       ` Kees Cook
2012-10-03 21:31         ` Frederic Weisbecker
2012-10-08 22:08     ` Kees Cook
2012-10-08 23:53       ` Greg Kroah-Hartman
2012-10-09  0:46         ` Kees Cook
2012-10-09  1:20           ` Greg Kroah-Hartman
2012-10-09  1:26           ` Paul E. McKenney
2012-10-09  1:57             ` Kees Cook
2012-10-09  2:47               ` Stephen Rothwell
2012-10-09  6:01                 ` Kees Cook
2012-12-16  4:29     ` Jan Engelhardt
2012-12-16 16:19       ` Paul E. McKenney
2012-10-03 23:29 ` Guenter Roeck
2012-10-03 23:33   ` Kees Cook
2012-10-03 23:37     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121007201854.GA6628@redhat.com \
    --to=davej@redhat.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=fweisbec@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=serge.hallyn@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).