mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Michal Piotrowski <michal.k.k.piotrowski@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: 2.6.22-git* regression: Kconfig prompts without help text
Date: Wed, 18 Jul 2007 18:00:07 +0200	[thread overview]
Message-ID: <469E3907.5030708@s5r6.in-berlin.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0707181634100.5385@fbirervta.pbzchgretzou.qr>

Jan Engelhardt wrote:
> On Jul 16 2007 20:49, Stefan Richter wrote:
>>
>>It is an error to add visible Kconfig options without help text.  Among
>>them are the new "menuconfig" options.  Jan obviously never uses "make
>>oldconfig".
> 
> Untrue. Users of menuconfig/xconfig/gconfig who do not know what an
> item is supposed to do would not get any helptext either.

I mentioned 'make oldconfig' because there you can't get a preview of
what other options you are perhaps about to enable or disable.

> It's just that I did not quite know what helptext to put there
> besides some trivial "enable this to see more fluffy options from
> this category". Feel free to add Blame-From: <srichter> :)

Maybe I'm extraordinarily dumb, but I felt unable to determine for sure
what consequences enabling or disabling some of those new prompts had
when I ran 'make oldconfig' for the first time in a post-2.6.22 tree.

Will saying Y merely present further options, or will it actually cause
something to be built?

> But see below.
> 
>>Most of these options were added after 2.6.22:
>>
>>BLK_DEV
>>HID_SUPPORT
>>INSTRUMENTATION
>>MACINTOSH_DRIVERS
>>MISC_DEVICES
>>USB_SUPPORT
>>
>>Here are suggestions for help texts.  Please verify if they are correct
>>and check whether there are more new (menuconfig) options without help
>>texts.
> 
> Other config options without text include:
> 
> CRYPTO_HW       (b511431d85948823ec58639bd3137b910964be34)
> AUXDISPLAY      (f5920969fb9e29c9d60568864d0a56fe85e8f4b6)
> VIRTUALIZATION  (de062065a5293d8f434acb2d6ba5df87ad76bbd9)
> ATM_DRIVERS     (4151ce3159c18a990da7fd6f0fe36c73d1c40f87)
> NETDEV_1000     (f30486d57bceec2364aa696403d64429ada61b60)
> NETDEV_10000    (f30486d57bceec2364aa696403d64429ada61b60)
> 
> Thanks for the starting help texts. I have produced a cumulative patch
> with both yours and the extra ones listed above.

Thanks for making an actual patch out of it and adding these other bits.

> Can we somehow sneak
> this directly in without split-to-maintainers? tis' just some help text.
> (Patch below)
> 
>>PS:
>>
>>I believe one possible *bug* of this menuconfig stuff is that if (1.)
>>user X disables menuconfig A in linux-2.6.x because nothing interesting
>>for him is in there, (2.) developer Y adds something very interesting in
>>menu A in linux-2.6.x+1, --> (3.) user X will miss this new option when
>>he runs "make oldconfig" when switching to linux-2.6.x+1 because
>>everything between 'if A'...'endif # A' will be invisible and disabled.
> 
> If I once said "I don't want no USB", I do not want to be prompted in a later
> version for USB_COFFEE_PAD. :)

Sure, if I disable USB now I expect that I may possibly miss
USB_COFFEE_PAD in 2.6.47.  That wouldn't worry me.

But what about loosely defined categories like BLK_DEV, INSTRUMENTATION,
MISC_DEVICES?  What functionality will be provided by their suboptions
in 2.6.47?
-- 
Stefan Richter
-=====-=-=== -=== =--=-
http://arcgraph.de/sr/

  reply	other threads:[~2007-07-18 16:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-16 18:49 Stefan Richter
2007-07-18 15:18 ` Jan Engelhardt
2007-07-18 16:00   ` Stefan Richter [this message]
2007-07-18 16:41   ` Randy Dunlap
2007-07-18 17:17     ` Jan Engelhardt
2007-07-18 17:34       ` Randy Dunlap
2007-07-18 17:55         ` Jan Engelhardt
2007-07-18 18:04           ` Randy Dunlap
2007-07-18 18:33             ` Jan Engelhardt
2007-07-18 18:37               ` Adrian Bunk
2007-07-19 20:26       ` Geert Uytterhoeven
2007-07-19 20:49         ` Stefan Richter
2007-07-19 21:05           ` Geert Uytterhoeven

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=469E3907.5030708@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=akpm@linux-foundation.org \
    --cc=jengelh@computergmbh.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.k.k.piotrowski@gmail.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

all inboxes | Powered by JetHome®