[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120119080955.GA2274@turtle.usersys.redhat.com>
Date: Thu, 19 Jan 2012 09:09:55 +0100
From: Andrew Jones <drjones@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: rientjes@...gle.com, mingo@...e.hu, david.woodhouse@...el.com,
linux-kernel@...r.kernel.org, gregkh@...e.de, davem@...emloft.net,
axboe@...nel.dk, arnd@...db.de, holt@....com,
linux-arch@...r.kernel.org, linux@....linux.org.uk,
hskinnemoen@...il.com, egtvedt@...fundet.no, msalter@...hat.com,
a-jacquiot@...com, starvik@...s.com,
jesper nilsson <jesper.nilsson@...s.com>, dhowells@...hat.com,
takata@...ux-m32r.org, geert@...ux-m68k.org,
yasutake koichi <yasutake.koichi@...panasonic.com>,
jonas@...thpole.se, kyle@...artin.ca, deller@....de,
jejb@...isc-linux.org, chris@...kel.net, greg@...ah.com,
davej@...hat.com, airlied@...ux.ie, jkosina@...e.cz,
mchehab@...radead.org, johannes@...solutions.net,
linville@...driver.com
Subject: Re: [PATCH] kconfig: untangle EXPERT and EMBEDDED
On Wed, Jan 18, 2012 at 12:28:30PM -0800, Andrew Morton wrote:
> And ditto EXPERT. Is there really any benefit in hiding config options
> from developers so they won't burn their fingers? Or is there some
> other reason for EXPERT?
The initial motivation for this patch actually comes from some backlash I
got when submitting a different patch. The other patch attempted to change
a silent config option, e.g.
config FOO
def_bool y
depends on BAR && BAZ
to one where it could be configurable, e.g.
config FOO
bool "This is Foo"
default y
depends on BAR && BAZ
help
Foo does FOObulously cool stuff
I needed it configurable because the default was y and I wanted to make it
n in my config. The backlash I got was that the configmenu was already too
complex, and thus this config option had been made silent to reduce that
complexity. My need to change the default was indeed for a very specific
purpose, and nobody else cared about it. Even though I was able to point
out another, more general, reason one might want to configure out that
option, it really didn't look like the patch was going anywhere. So I
looked around for another solution and found EXPERT. Changing the option
to
config FOO
bool "This is Foo" if EXPERT
default y
depends on BAR && BAZ
help
Foo does FOObulously cool stuff
seemed like a great way to solve the configmenu complexity issue, and get
my configurablity. The documentation for EXPERT
This option allows certain base kernel options and settings
to be disabled or tweaked. This is for specialized
environments which can tolerate a "non-standard" kernel.
Only use this if you really know what you are doing.
indicated to me that that's precisely what EXPERT was for. Unfortunately a
quick experiment showed that it messes with config options, as well as
expose them for disabling and tweaking.
That's the initial motivation for fixing EXPERT. Before posting this patch
though I came up with another motivation. If this patch was merged I was
planning to send an RFC asking if it would make sense to apply EXPERT to
most/all of the config options that have sentences like
"If unsure select y, only disable if you know what you're doing"
Options like these also sound like expert options to me, and so there's no
reason to have to visit them while configuring a standard kernel. You'd
just select the default anyway.
>
> Anyway, we already have a way to prevent fingers from getting burnt:
> defconfig. Start out with that and carefully modify it.
>
Yes, this is good, but it doesn't solve the silent option problem. For the
example above
config FOO
def_bool y
depends on BAR && BAZ
I can't just say FOO=n in my own personal config to override it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists