From: Tim Shepard <shep@alum.mit.edu>
To: linux-kernel@vger.kernel.org
Subject: CONFIG_EXPERT is a booby trap
Date: Sun, 30 Sep 2012 22:21:45 -0400 [thread overview]
Message-ID: <E1TIVdh-0007iT-00@www.xplot.org> (raw)
A month or two ago when I attempted to upgrade from 3.4 to 3.5 on my
MacBook Pro laptop, in preparation to try an interesting patch to TCP
developed against 3.5 by a colleague, my keyboard stopped working. I
tried bisecting, but that lead to nowhere useful and much confusion.
It turns out that while I was looking for some debug options under
"General setup" and "Kernel hacking", I turned on "Configure standard
kernel features (expert users)" which is also known as CONFIG_EXPERT.
I read the documentation for that option, and I perused the options
which appeared underneath when it was turned on, thought to myself "oh,
hmm, I don't want to change any of these" and wandered off and
eventually found what I was actually looking for elsewhere in the
kernel configuration tree.
This weekend I finally figured out why the keyboard in my MacBook Pro
stopped working between 3.4 and 3.5.
When I turned on CONFIG_EXPERT it turned off CONFIG_HID_APPLE. There
was no warning that selecting "Configure standard kernel features" will
invisibly turn off needed things elsewhere in the configuration tree.
Something needs to be fixed, but it's not obvious that any simple change
will work without causing other troubles.
I've read some of the lkml history history and learned that references
to CONFIG_EXPERT (like the one on CONFIG_HID_APPLE) used to be
references to CONFIG_EMBEDDED, so CONFIG_EXPERT used to mean something
else.
Maybe "make menuconfig" should show you all the things that you've just
changed and ask for confirmation when changing one configuration option
causes actual configuration changes elsewhere in the tree.
And may I suggest that CONFIG_EXPERT should be factored into two
CONFIGs, one of which makes configuration things visible, and another
which changes the default values to something more appropriate for
embedded systems (perhaps call it CONFIG_EMBEDDED_DEFAULTS). That way
you'd have to select CONFIG_EXPERT, and then select the
CONFIG_EMBEDDED_DEFAULTS option that CONFIG_EXPERT made visible to
actually change any configuration, and the documentation for
CONFIG_EMBEDDED_DEFAULTS could explain that it changes defaults
throughout the tree (and selecting CONFIG_EXPERT alone would not go off
and muck things up with no warning).
The transition plan such a factoring needs some further thought to avoid
breaking anyone's current configuration when they "make oldconfig".
-Tim Shepard
shep@alum.mit.edu
next reply other threads:[~2012-10-01 2:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-01 2:21 Tim Shepard [this message]
2012-10-01 3:24 ` CONFIG_EXPERT is a booby trap Randy Dunlap
2012-10-01 4:32 ` Tim Shepard
2012-10-01 18:07 ` Olaf Titz
2012-10-02 3:44 ` David Rientjes
2012-10-01 23:06 ` Josh Triplett
2012-10-01 9:09 ` Mikael Pettersson
2012-10-02 3:49 ` 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=E1TIVdh-0007iT-00@www.xplot.org \
--to=shep@alum.mit.edu \
--cc=linux-kernel@vger.kernel.org \
/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