All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Adrian Bunk <bunk@stusta.de>
Cc: Arjan van de Ven <arjan@infradead.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: Please revert "debug: Make CONFIG_EXPERT select CONFIG_DEBUG_KERNEL to unhide debug options"
Date: Wed, 12 Oct 2011 10:38:01 +0200	[thread overview]
Message-ID: <20111012083801.GA27853@elte.hu> (raw)
In-Reply-To: <20111010121340.GA3731@localhost.pp.htv.fi>


* Adrian Bunk <bunk@stusta.de> wrote:

> On Mon, Oct 10, 2011 at 12:21:21PM +0200, Ingo Molnar wrote:
> > 
> > * Adrian Bunk <bunk@stusta.de> wrote:
> > 
> > > On Mon, Oct 10, 2011 at 09:29:48AM +0200, Ingo Molnar wrote:
> > > > * Adrian Bunk <bunk@stusta.de> wrote:
> > > >...
> > > > I think you are wrong not just about that detail but about the whole 
> > > > premise of your complaint as well:
> > > > 
> > > > >  config DEBUG_BUGVERBOSE
> > > > > -	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
> > > > > +	bool "Verbose BUG() reporting (adds 70K)" if EXPERT
> > > > > 
> > > > > This part of the patch would have been the correct and complete 
> > > > > solution for DEBUG_BUGVERBOSE.
> > > > 
> > > > Not really - it's a debugging-only option and when i turn on 
> > > > CONFIG_DEBUG_KERNEL I expect to have full config control over all 
> > > > debug options - with sane defaults provided.
> > > 
> > > Then you would have to remove the dependency on EXPERT from the prompt, 
> > > and allow unsetting DEBUG_BUGVERBOSE with EXPERT=n, DEBUG_KERNEL=y.
> > > 
> > > Note that this is completely unrelated to the commit we are discussing,
> > > since commit f505c553 has no effect in the EXPERT=n case you are 
> > > discussing here.
> > > 
> > > > I definitely don't want a debugging option to depend on 
> > > > CONFIG_EXPERT.
> > > 
> > > DEBUG_BUGVERBOSE does not depend on EXPERT.
> > > 
> > > But EXPERT is currently required for disabling it.
> > 
> > Correct - that's a further variation. In the case of debug options 
> > that we *really* don't want normal users to disable we do something 
> > like this:
> > 
> >  config DEBUG_BUGVERBOSE
> >          bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
> > 
> > Commit f505c553 ("debug: Make CONFIG_EXPERT select 
> > CONFIG_DEBUG_KERNEL to unhide debug options") allows this line to be 
> > further simplified into:
> > 
> >         bool "Verbose BUG() reporting (adds 70K)" if EXPERT
> > 
> > ... but this was not the main purpose of the commit - nor is this 
> > simplification strictly necessary.
> 
> You do not need commit f505c553 for that, the dependency of this 
> prompt on DEBUG_KERNEL should be removed in any case.

An opt-out model is more maintainable here than an opt-in method. 
People will get debug dependencies right most of the time - but 
getting debug *and* CONFIG_EXPERT interactions right is on the 
backburner generally.

So we are better off if CONFIG_EXPERT simply implies (selects) 
CONFIG_KERNEL_DEBUG - makes CONFIG_EXPERT an invariant as far as 
debugging features are concerned and reduces/eliminates the trickle 
of avoidable CONFIG_EXPERT tweaking patches in lib/Kconfig.debug.

> Why do you want to make life harder for people with EXPERT=y by not 
> allowing them to turn this off if they want to?

It's simpler to have one flat CONFIG_EXPERT=y option to gain broad 
expert-configurability of core debug functionality of the kernel.

It should arguably not explode the options to *all* drivers of the 
kernel:

> When configuring his kernel, a user set MISC_FILESYSTEMS=n.
> 
> Now he sets EXPERT=y and runs "make oldconfig".
>
> Why would it make sense that he is now asked for each of these 
> filesystems whether he wants to enable it?

I agree with you that filesystems are more like drivers here and 
should probably not be selected by CONFIG_EXPERT. It's up to the VFS 
folks whether they consider experts to be frequent requestors. 
(probably not)

But the important case here is the situation outlined in the 
changelog, that a default-y core kernel option such as BUGVERBOSE 
unconditionally *adds* code. Core kernel debugging code is an area 
that by its nature has and is bound to have such options - 
MISC_FILESYSTEMS probably not.

Thanks,

	Ingo

  reply	other threads:[~2011-10-12  8:39 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-30 13:42 Please revert "debug: Make CONFIG_EXPERT select CONFIG_DEBUG_KERNEL to unhide debug options" Adrian Bunk
2011-09-30 15:05 ` Josh Triplett
2011-09-30 15:25   ` Frederic Weisbecker
2011-09-30 15:32     ` Frederic Weisbecker
2011-09-30 15:54     ` Adrian Bunk
2011-09-30 15:50   ` Adrian Bunk
2011-10-10  7:29     ` Ingo Molnar
2011-10-10  8:48       ` Adrian Bunk
2011-10-10  9:44         ` Mike Galbraith
2011-10-10 10:21         ` Ingo Molnar
2011-10-10 12:13           ` Adrian Bunk
2011-10-12  8:38             ` Ingo Molnar [this message]
2011-10-20 21:41               ` Adrian Bunk
2011-10-21  8:19                 ` Michal Marek
2011-10-21  9:22                   ` Adrian Bunk
2011-10-21 12:37                     ` Michal Marek
2011-10-21 16:12                       ` Adrian Bunk

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=20111012083801.GA27853@elte.hu \
    --to=mingo@elte.hu \
    --cc=arjan@infradead.org \
    --cc=bunk@stusta.de \
    --cc=fweisbec@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.