linux-kernel - Re: [PATCH] kconfig: untangle EXPERT and EMBEDDED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120123134632.GA8235@turtle.usersys.redhat.com>
Date:	Mon, 23 Jan 2012 14:46:43 +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:
> 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
--
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/