public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* CONFIG_EXPERT is a booby trap
@ 2012-10-01  2:21 Tim Shepard
  2012-10-01  3:24 ` Randy Dunlap
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Tim Shepard @ 2012-10-01  2:21 UTC (permalink / raw)
  To: linux-kernel



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

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-10-02  3:49 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-01  2:21 CONFIG_EXPERT is a booby trap Tim Shepard
2012-10-01  3:24 ` 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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox