The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Paul Bolle <pebolle@tiscali.nl>
Cc: Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Michal Hocko <mhocko@suse.cz>,
	Vladimir Davydov <vdavydov@parallels.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Bertrand Jacquin <beber@meleeweb.net>,
	"Luis R. Rodriguez" <mcgrof@suse.com>,
	Iulia Manda <iulia.manda21@gmail.com>,
	Pranith Kumar <bobby.prani@gmail.com>,
	Clark Williams <clark.williams@gmail.com>,
	Mel Gorman <mgorman@suse.de>,
	Randy Dunlap <rdunlap@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert
Date: Mon, 11 May 2015 14:47:10 -0700	[thread overview]
Message-ID: <20150511214710.GA15791@jtriplet-mobl1> (raw)
In-Reply-To: <1431379948.2398.102.camel@x220>

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

  reply	other threads:[~2015-05-11 21:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-11 18:13 [PATCH] init/Kconfig: Fix break in middle of EXPERT menu Josh Triplett
2015-05-11 18:23 ` Randy Dunlap
2015-05-11 20:23 ` [PATCH 2/1] init/Kconfig: Split expert menu into a separate file, init/Kconfig.expert Josh Triplett
2015-05-11 21:01   ` Paul Bolle
2015-05-11 21:18     ` Josh Triplett
2015-05-11 21:32       ` Paul Bolle
2015-05-11 21:47         ` Josh Triplett [this message]
2015-05-11 22:01           ` Paul Bolle
2015-05-11 22:40             ` Josh Triplett
2015-05-11 21:50   ` Paul Bolle
2015-05-11 22:04     ` Josh Triplett
2015-05-11 22:15       ` Paul Bolle
2015-05-28  8:13         ` Paul Bolle
2015-05-11 22:36   ` Luis R. Rodriguez
2015-05-11 22:51     ` Josh Triplett
2015-05-12  7:04 ` [PATCH] init/Kconfig: Fix break in middle of EXPERT menu Ingo Molnar
2015-05-12  7:08   ` Josh Triplett

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=20150511214710.GA15791@jtriplet-mobl1 \
    --to=josh@joshtriplett.org \
    --cc=akpm@linux-foundation.org \
    --cc=beber@meleeweb.net \
    --cc=bobby.prani@gmail.com \
    --cc=clark.williams@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=hannes@cmpxchg.org \
    --cc=iulia.manda21@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mcgrof@suse.com \
    --cc=mgorman@suse.de \
    --cc=mhocko@suse.cz \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=pebolle@tiscali.nl \
    --cc=rdunlap@infradead.org \
    --cc=vdavydov@parallels.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