CONFIG_EXPERT is a booby trap

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

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

./drivers/hid/Kconfig: default !EXPERT

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

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

-Tim Shepard
[email protected]

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

$ 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

Quoted 45 lines · Tim Shepard

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

Quoted 2 lines

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

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