On Thu, 3 Jun 2010, Russell King wrote: > On Thu, Jun 03, 2010 at 12:49:58PM -0700, Daniel Walker wrote: > > So your saying it would drop all the selects, but keep the selected > > options in tact? Or it would just turn off all the selected options? > > config MACH_HALIBUT > bool "Halibut Board (QCT SURF7201A)" > select I2C if STD_CONFIG > select I2C_WHATEVER if STD_CONFIG > ... > > That means if you enable STD_CONFIG, you'll get everything that's required > selected. If you then disable STD_CONFIG, I believe Kconfig leaves > everything that was selected as still being selected. > > So, what you _could_ do is start off with a blank configuration, then > configure a kernel with STD_CONFIG enabled and you end up with everything > that's required. If you then want to disable something that's selected, > turn off STD_CONFIG first, and you'll be able to turn off individual > options. I think this certainly makes sense, at least as a proof of concept. If we end up with lots of select XYZ if STD_CONFIG then at that point it might be a good idea to introduce some variations in the Kconfig language directly. Something like a multi-priority select statement that would either: - provide the minimum amount of choice to the user and forcefully "select" a default set of options expected to enable all features of the target hardware, or - let the user see the "preselected" options with a chance to turn it off, but provide a y by default right away, or - ignore those "preselect" statement entirely, as some expert mode. Of course the 2nd and 3rd options wouldn't necessarily mean an optimal or even working kernel configuration would be produced. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
