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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/