From: Ingo Molnar <mingo@xxxxxxx> Date: Fri, 25 Apr 2008 10:00:33 +0200 > personally i always considered this a Kconfig bug - although it's > probably not an easy issue to solve. (what if there are conflicts? What > if a driver's select choice disables another driver, without the user > being openly aware of this side-effect?) It definitely is seen as a bug in the context of the alternative, using 'depend' and then forcing people to spend a lot of time trying to figure out what magic option they have to enable just to turn on the driver for their wireless card. > the patch below fixes it here but it's still kind of a band-aid - what > if the Kconfig structure of LEDS get modified - does that have to be > propagated to all LEDS using drivers? I dont think this necessity of > open-coded dependency resolution is maintainable in the long run. Yes, that would be the way to work around this. iwlwifi used LEDS and would need a similar workaround. Maybe part of the problem is the "if NEW_LEDS" construct used by drivers/leds/Kconfig? Perhaps we could make this work if NEW_LEDS appeared as an explicit dependency of the various LEDS_* options. Or, maybe it works to make LEDS_CLASS select NEW_LEDS. I don't know, this is just a gigantic maze, and I'm just throwing out random ideas. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
