Messages in this thread | | | Date | Wed, 9 Jan 2013 12:38:53 +0000 | From | Russell King - ARM Linux <> | Subject | Re: [PATCH 2/3] ARM: ux500: Turn on the 'heartbeat' LED trigger |
| |
On Wed, Jan 09, 2013 at 12:23:23PM +0000, Lee Jones wrote: > Excuse my ignorance, but I'm a little confused by this. > > What's the difference between 'select <OPTION>' in the Kconfig and > 'CONFIG_<OPTION>=y' in the defconfig; besides the fact that if we > do it in the Kconfig file, we can be more selective with regards to > which platform it gets enabled on?
Take this in Kconfig:
config FOO bool "FOO option" select BAR
config BAR bool "BAR option"
Now, irrespective of the default configuration file being used: - if you don't enable FOO, then you can enable _and_ _disable_ BAR according to your needs. - if you enable FOO, then BAR will be _forcefully_ enabled and you can't turn it off without first disabling FOO.
The default configuration file will specify the _default_ values for these options, but if FOO ends up being enabled, BAR will be forcefully enabled irrespective of what's in the configuration file.
With this instead:
config FOO bool "FOO option"
config BAR bool "BAR option"
Then, the two options are independent. They can be enabled and disabled by the configuration completely independently. However, their default values come from the default configuration file. So, if the config file has:
CONFIG_FOO=y CONFIG_BAR=y
and you do a 'make oldconfig' then they will remain set. If you use one of the configuration editing tools, you'll be presented with them already enabled, and you can turn them off independently.
So, putting this stuff in the default configuration file allows _non-mandatory_ options to be disabled should the user desire without the user having to edit the configuration files.
If a user has to edit the configuration files in order to configure the kernel as they desire, then the configuration system has failed - or we have failed to properly think out how to represent the allowable configurations.
| |