From: Andrew Jones <drjones@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: rientjes@google.com, mingo@elte.hu, david.woodhouse@intel.com,
linux-kernel@vger.kernel.org, gregkh@suse.de,
davem@davemloft.net, axboe@kernel.dk, arnd@arndb.de,
holt@sgi.com, linux-arch@vger.kernel.org, linux@arm.linux.org.uk,
hskinnemoen@gmail.com, egtvedt@samfundet.no, msalter@redhat.com,
a-jacquiot@ti.com, starvik@axis.com,
jesper nilsson <jesper.nilsson@axis.com>,
dhowells@redhat.com, takata@linux-m32r.org, geert@linux-m68k.org,
yasutake koichi <yasutake.koichi@jp.panasonic.com>,
jonas@southpole.se, kyle@mcmartin.ca, deller@gmx.de,
jejb@parisc-linux.org, chris@zankel.net, greg@kroah.com,
davej@redhat.com, airlied@linux.ie, jkosina@suse.cz,
mchehab@infradead.org, johannes@sipsolutions.net,
linville@tuxdriver.com
Subject: Re: [PATCH] kconfig: untangle EXPERT and EMBEDDED
Date: Mon, 23 Jan 2012 14:46:43 +0100 [thread overview]
Message-ID: <20120123134632.GA8235@turtle.usersys.redhat.com> (raw)
In-Reply-To: <20120118122830.037f1e29.akpm@linux-foundation.org>
On Wed, Jan 18, 2012 at 12:28:30PM -0800, Andrew Morton wrote:
> time. But I suggest that we tip both CONFIG_EXPERT and CONFIG_EMBEDDED
> into the ole bit bucket. What do you guys think would be the negative
> consequences of doing this?
I thought EXPERT was the best way to manage the visibility of expert
options, but probably not, since it's prone to silent default changing. I
think it would be safer if the kconfig language had more support for this
visibility control. Maybe we need another miscellaneous option, like
'option visibility=<level>', level = {low, normal, high, experimental}.
low means practically grayed out (hopefully allowing the eye of the user
to effectively not see it), normal would be a noop, high makes it stand
out, and experimental would be like high, except also throw a canned
sentence in that says it's not ready for production. (This additional
focus on EXPERIMENTAL was inspired by your comments on it possibly
deserving a special color or something.) Of course, additional or
different levels could be conceived of, but in general I think we need
better ways to supply hints to kconfig frontends about visibility.
Something that can't get tangled up with default values.
Drew
next prev parent reply other threads:[~2012-01-23 13:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 15:16 [PATCH] kconfig: untangle EXPERT and EMBEDDED Andrew Jones
2012-01-11 21:57 ` David Rientjes
2012-01-12 9:18 ` Arnd Bergmann
2012-01-12 10:18 ` Andrew Jones
2012-01-12 21:06 ` David Rientjes
2012-01-13 8:51 ` Andrew Jones
2012-01-13 10:53 ` David Rientjes
2012-01-13 12:22 ` Andrew Jones
2012-01-13 21:27 ` David Rientjes
2012-01-16 9:20 ` Andrew Jones
2012-01-16 23:28 ` David Rientjes
2012-01-17 14:27 ` Andrew Jones
2012-01-17 20:46 ` David Rientjes
2012-01-18 8:14 ` Andrew Jones
2012-01-18 9:19 ` David Rientjes
2012-01-16 15:31 ` Jerome Marchand
2012-01-16 23:37 ` David Rientjes
2012-01-17 14:46 ` Andrew Jones
2012-01-17 20:54 ` David Rientjes
2012-01-18 8:51 ` Jerome Marchand
2012-01-18 8:56 ` Andrew Jones
2012-01-18 9:31 ` David Rientjes
2012-01-18 9:54 ` Andrew Jones
2012-01-18 9:38 ` Andrew Jones
2012-01-12 20:59 ` David Rientjes
2012-01-16 15:40 ` Jerome Marchand
2012-01-16 15:50 ` Andrew Jones
2012-01-16 17:34 ` Geert Uytterhoeven
2012-01-17 8:28 ` Andrew Jones
2012-01-18 11:08 ` Andrew Jones
2012-01-18 20:28 ` Andrew Morton
2012-01-18 20:46 ` Russell King - ARM Linux
2012-01-18 21:04 ` Alexey Dobriyan
2012-01-18 21:36 ` Andrew Morton
2012-01-18 21:48 ` Paul Bolle
2012-01-18 21:55 ` Andrew Morton
2012-01-18 22:13 ` Russell King - ARM Linux
2012-01-18 22:06 ` Alexey Dobriyan
2012-01-18 22:13 ` Dave Jones
2012-01-19 8:09 ` Andrew Jones
2012-01-23 13:46 ` Andrew Jones [this message]
2012-01-24 0:43 ` David Rientjes
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=20120123134632.GA8235@turtle.usersys.redhat.com \
--to=drjones@redhat.com \
--cc=a-jacquiot@ti.com \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=chris@zankel.net \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=david.woodhouse@intel.com \
--cc=deller@gmx.de \
--cc=dhowells@redhat.com \
--cc=egtvedt@samfundet.no \
--cc=geert@linux-m68k.org \
--cc=greg@kroah.com \
--cc=gregkh@suse.de \
--cc=holt@sgi.com \
--cc=hskinnemoen@gmail.com \
--cc=jejb@parisc-linux.org \
--cc=jesper.nilsson@axis.com \
--cc=jkosina@suse.cz \
--cc=johannes@sipsolutions.net \
--cc=jonas@southpole.se \
--cc=kyle@mcmartin.ca \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linville@tuxdriver.com \
--cc=mchehab@infradead.org \
--cc=mingo@elte.hu \
--cc=msalter@redhat.com \
--cc=rientjes@google.com \
--cc=starvik@axis.com \
--cc=takata@linux-m32r.org \
--cc=yasutake.koichi@jp.panasonic.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).