Re: [PATCH] make CONFIG_EXPERIMENTAL invisible and default

[Frederic Weisbecker]

2012/10/5 Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/