[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070206153413.GA10167@linux-sh.org>
Date: Wed, 7 Feb 2007 00:34:13 +0900
From: Paul Mundt <lethal@...ux-sh.org>
To: Matt Mackall <mpm@...enic.com>
Cc: David Woodhouse <dwmw2@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error
On Mon, Feb 05, 2007 at 11:46:12PM -0600, Matt Mackall wrote:
> I'd be happy to turn this into CONFIG_NONSTANDARD or
> CONFIG_EXPERT, which is how I described it in the Kconfig help texts:
>
> menuconfig EMBEDDED
> bool "Configure standard kernel features (for small systems)"
> help
> 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.
>
> A number of current users are indeed bogus. Stuff like:
>
> config SUPERH
> bool
> default y
> select EMBEDDED
>
> Just because you're using a SuperH board doesn't mean you want to turn
> off standard features.
>
The only thing bogus is the CONFIG_EMBEDDED use itself, if it were only
limited to turning options off, you'd be correct, but both PCI and IDE
use it for other things. We specifically wanted it for IDE in this case.
I'd be quite happy to see CONFIG_EMBEDDED separated entirely from the
"advanced/expert/screwing aunt tillie" selection menu, or whatever we're
choosing to call it these days. Then we wouldn't have to deal with these
confusing defconfigs that expose far more than most users are going to
care about.
There are a number of other architectures that do this too, so it may be
worth separating so we can finally get rid of the confusion.
-
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