From: Dave Jones <davej@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Kees Cook <keescook@chromium.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: Wed, 3 Oct 2012 15:36:53 -0400 [thread overview]
Message-ID: <20121003193653.GB30477@redhat.com> (raw)
In-Reply-To: <20121003174606.GB637@somewhere>
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
next prev parent reply other threads:[~2012-10-03 19:55 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 [this message]
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
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=20121003193653.GB30477@redhat.com \
--to=davej@redhat.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=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).