linux-kernel.vger.kernel.org archive mirror
 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

* Re: CONFIG_EXPERT is a booby trap
  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 23:06   ` Josh Triplett
  2012-10-01  9:09 ` Mikael Pettersson
  2012-10-02  3:49 ` David Rientjes
  2 siblings, 2 replies; 8+ messages in thread
From: Randy Dunlap @ 2012-10-01  3:24 UTC (permalink / raw)
  To: Tim Shepard; +Cc: linux-kernel

On 09/30/2012 07:21 PM, Tim Shepard wrote:

> 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".


I don't disagree with you that it can be a problem, but
the help text for CONFIG_EXPERT does say:

	Only use this if you really know what you are doing.


Anyway, the hid drivers are certainly a big user of this mechanism.
Many of them are like HID_APPLE:

config HID_APPLE
	tristate "Apple {i,Power,Mac}Books" if EXPERT
	depends on (USB_HID || BT_HIDP)
	default !EXPERT


-- 
~Randy

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: CONFIG_EXPERT is a booby trap
  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
  1 sibling, 2 replies; 8+ messages in thread
From: Tim Shepard @ 2012-10-01  4:32 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: linux-kernel



Interestingly, of the 26 configs that use EXPERT in the default
clause, 15 of them are in drivers/hid (see below).

			-Tim Shepard
			 shep@alum.mit.edu

 - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - - 

$ find . -type f -name Kconfig'*' -print | xargs fgrep default | grep EXPERT 
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/hid/Kconfig:  default !EXPERT
./drivers/media/common/tuners/Kconfig:  default y if !EXPERT
./drivers/media/common/tuners/Kconfig:  default y if EXPERT
./drivers/media/dvb/frontends/Kconfig:  default y if EXPERT
./drivers/media/video/Kconfig:  default y if !EXPERT
./init/Kconfig: default !EXPERT
./lib/Kconfig.debug:    default !EXPERT
./net/rfkill/Kconfig:   default y if !EXPERT
./usr/Kconfig:  default !EXPERT
./usr/Kconfig:  default !EXPERT
./usr/Kconfig:  default !EXPERT
./usr/Kconfig:  default !EXPERT

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: CONFIG_EXPERT is a booby trap
  2012-10-01  2:21 CONFIG_EXPERT is a booby trap Tim Shepard
  2012-10-01  3:24 ` Randy Dunlap
@ 2012-10-01  9:09 ` Mikael Pettersson
  2012-10-02  3:49 ` David Rientjes
  2 siblings, 0 replies; 8+ messages in thread
From: Mikael Pettersson @ 2012-10-01  9:09 UTC (permalink / raw)
  To: Tim Shepard; +Cc: linux-kernel

Tim Shepard writes:
 > 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.

"diff" the before and after .config files.  That's alerted me to unexpected
changes (not just "where did CONFIG_${foo} go?" but also "wtf is CONFIG_${bar}
doing there?") on numerous occasions.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: CONFIG_EXPERT is a booby trap
  2012-10-01  4:32   ` Tim Shepard
@ 2012-10-01 18:07     ` Olaf Titz
  2012-10-02  3:44     ` David Rientjes
  1 sibling, 0 replies; 8+ messages in thread
From: Olaf Titz @ 2012-10-01 18:07 UTC (permalink / raw)
  To: linux-kernel

In article <E1TIXga-0008T1-00@www.xplot.org> you write:
> Interestingly, of the 26 configs that use EXPERT in the default
> clause, 15 of them are in drivers/hid (see below).

Without looking at the code I assume this is due to copy/paste.
Someone perhaps once wrote

> ./drivers/hid/Kconfig:  default !EXPERT

when he really intended

> ./drivers/media/common/tuners/Kconfig:  default y if !EXPERT

Olaf

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: CONFIG_EXPERT is a booby trap
  2012-10-01  3:24 ` Randy Dunlap
  2012-10-01  4:32   ` Tim Shepard
@ 2012-10-01 23:06   ` Josh Triplett
  1 sibling, 0 replies; 8+ messages in thread
From: Josh Triplett @ 2012-10-01 23:06 UTC (permalink / raw)
  To: Randy Dunlap; +Cc: Tim Shepard, linux-kernel

On Sun, Sep 30, 2012 at 08:24:46PM -0700, Randy Dunlap wrote:
> On 09/30/2012 07:21 PM, Tim Shepard wrote:
> 
> > 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".
> 
> 
> I don't disagree with you that it can be a problem, but
> the help text for CONFIG_EXPERT does say:
> 
> 	Only use this if you really know what you are doing.
> 
> 
> Anyway, the hid drivers are certainly a big user of this mechanism.
> Many of them are like HID_APPLE:
> 
> config HID_APPLE
> 	tristate "Apple {i,Power,Mac}Books" if EXPERT
> 	depends on (USB_HID || BT_HIDP)
> 	default !EXPERT

This just seems blatantly wrong to me.  "if EXPERT" seems fine, but I'd
argue that these should just say "default y".  Then, turning off EXPERT
will give the *option* of turning them off, without turning them off by
default.  I think that reasoning applies to everything that currently
has EXPERT as part of its default expression.

That seems like an easy enough change to make, independently from any
addition of a CONFIG_EMBEDDED_DEFAULTS or similar.

- Josh Triplett

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: CONFIG_EXPERT is a booby trap
  2012-10-01  4:32   ` Tim Shepard
  2012-10-01 18:07     ` Olaf Titz
@ 2012-10-02  3:44     ` David Rientjes
  1 sibling, 0 replies; 8+ messages in thread
From: David Rientjes @ 2012-10-02  3:44 UTC (permalink / raw)
  To: Tim Shepard; +Cc: Randy Dunlap, linux-kernel

On Mon, 1 Oct 2012, Tim Shepard wrote:

> Interestingly, of the 26 configs that use EXPERT in the default
> clause, 15 of them are in drivers/hid (see below).
> 
> 			-Tim Shepard
> 			 shep@alum.mit.edu
> 
>  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  - - 
> 
> $ find . -type f -name Kconfig'*' -print | xargs fgrep default | grep EXPERT 
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/hid/Kconfig:  default !EXPERT
> ./drivers/media/common/tuners/Kconfig:  default y if !EXPERT
> ./drivers/media/common/tuners/Kconfig:  default y if EXPERT
> ./drivers/media/dvb/frontends/Kconfig:  default y if EXPERT
> ./drivers/media/video/Kconfig:  default y if !EXPERT
> ./init/Kconfig: default !EXPERT
> ./lib/Kconfig.debug:    default !EXPERT
> ./net/rfkill/Kconfig:   default y if !EXPERT
> ./usr/Kconfig:  default !EXPERT
> ./usr/Kconfig:  default !EXPERT
> ./usr/Kconfig:  default !EXPERT
> ./usr/Kconfig:  default !EXPERT

I don't think selecting CONFIG_EXPERT should change whether a config 
option is enabled or disabled by default, I think it should only change 
whether certain options are available for enabling or disabling.  These do 
need care when fixing, though, and in the above circumstances you may find 
that s/EXPERT/EMBEDDED/ is the right change.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: CONFIG_EXPERT is a booby trap
  2012-10-01  2:21 CONFIG_EXPERT is a booby trap Tim Shepard
  2012-10-01  3:24 ` Randy Dunlap
  2012-10-01  9:09 ` Mikael Pettersson
@ 2012-10-02  3:49 ` David Rientjes
  2 siblings, 0 replies; 8+ messages in thread
From: David Rientjes @ 2012-10-02  3:49 UTC (permalink / raw)
  To: Tim Shepard; +Cc: linux-kernel

On Sun, 30 Sep 2012, Tim Shepard wrote:

> 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).
> 

I think you can get away with changing everything that is doing "default 
!EXPERT" to do "default !EMBEDDED" since it's usually only done for things 
that are known not to be interesting for the embedded world and 
significantly increase the size of the kernel memory footprint.  What it's 
really saying is to "enable it by default on everything that doesn't need 
to make the smallest kernel possible."

Aside from that, separating CONFIG_EXPERT from CONFIG_EMBEDDED is 
something that has been discussed a few times and can be done when it 
makes clear sense and you can get consensus on the change.  We always 
accept patches.

^ 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;
as well as URLs for NNTP newsgroup(s).