[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150511214710.GA15791@jtriplet-mobl1>
Date: Mon, 11 May 2015 14:47:10 -0700
From: Josh Triplett <josh@...htriplett.org>
To: Paul Bolle <pebolle@...cali.nl>
Cc: Ingo Molnar <mingo@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Michal Hocko <mhocko@...e.cz>,
Vladimir Davydov <vdavydov@...allels.com>,
Johannes Weiner <hannes@...xchg.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Andy Lutomirski <luto@...capital.net>,
Bertrand Jacquin <beber@...eeweb.net>,
"Luis R. Rodriguez" <mcgrof@...e.com>,
Iulia Manda <iulia.manda21@...il.com>,
Pranith Kumar <bobby.prani@...il.com>,
Clark Williams <clark.williams@...il.com>,
Mel Gorman <mgorman@...e.de>,
Randy Dunlap <rdunlap@...radead.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate
file, init/Kconfig.expert
On Mon, May 11, 2015 at 11:32:28PM +0200, Paul Bolle wrote:
> On Mon, 2015-05-11 at 14:18 -0700, Josh Triplett wrote:
> > However, that would produce *two* entries under the "General setup"
> > menu: a yes/no entry "Configure standard kernel features (expert users)"
> > with no submenu, and a "Some separate menu prompt here" entry with a
> > submenu but no '[ ]' for a yes/no option. Integrating the two (without
> > using menuconfig's implicit "add stuff to submenu until an option's
> > prompt doesn't depend on this symbol" magic) requires new a kconfig
> > mechanism.
>
> The diff pasted at the end of this message, which I quickly cobbled
> together an applies on top of this 2/1, generates these two lines in
> menuconfig (for EXPERT = 'y')
> [*] Configure standard kernel features (expert users)
> Standard kernel features --->
>
> Is squashing those two lines worth a new kconfig mechanism?
In my opinion, yes. If you use the implicit (and error-prone)
menuconfig submenuing, you get a single entry with the '[ ]' and the
submenu. There are currently 272 instances of "menuconfig" in Kconfig
files. I'd like to have a less error-prone mechanism for people to use,
with an explicit "endmenu" at the end, and I don't want to leave any
incentive for people to need the more error-prone version.
I would be tempted to just make "menuconfig" require an endmenu, and
convert all users, but that would almost certainly break many
third-party users of kconfig. So instead, I'm currently extending
"menu" (which already expects "endmenu") to allow the syntax
"menu config SYMBOL", which acts like a combination of "config SYMBOL"
and a menu with "visible if SYMBOL". Diffstat for the patch I'm testing
right now:
scripts/kconfig/zconf.y | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
That seems worthwhile to have a less error-prone menu mechanism.
(The actual patch would also need to updated zconf.tab.c_shipped.)
(Also, the diff you posted would be smaller if you left "config EXPERT"
at the top of init/Kconfig.expert; why the move?)
- Josh Triplett
--
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