Managing Configuration Options

An earlier section in this chapter looked at compiling the fishing pole module only if the CONFIG_FISHING_POLE configuration option was set. Configuration options have been discussed in earlier chapters, too, but now let's look at actually adding a new one, continuing with the fishing pole example.

Thanks to the new "kbuild" system in the 2.6 kernel, adding new configuration options is very easy. All you have to do is add an entry to the Kconfig file responsible for the neck of the kernel source tree. For drivers, this is usually the very directory in which the source lives. If the fishing pole driver lives in drivers/char/, then you use drivers/char/Kconfig.

If you created a new subdirectory and want a new Kconfig file to live there, you have to source it from an existing Kconfig. You do this by adding a line such as

source "drivers/char/fishing/Kconfig"

to the existing Kconfig file, say drivers/char/Kconfig.

Entries in Kconfig are easy to add. The fishing pole module would look like

config FISHING_POLE
        tristate "Fish Master XL support"
        default n
        help
          If you say Y here, support for the Fish Master XL 2000 Titanium with
          computer interface will be compiled into the kernel and accessible via
          device node. You can also say M here and the driver will be built as a
          module named fishing.ko.

          If unsure, say N.

The first line defines what configuration option this entry represents. Note that the CONFIG_ prefix is assumed and not written.

The second line states that this option is a tristate, meaning that it can be built into the kernel (Y), built as a module (M), or not built at all (N). To disable the option of building as a modulesay, if this option represented a feature and not a moduleuse the directive bool instead of tristate. The quoted text following the directive provides the name of this option in the various configuration utilities.

The third line specifies the default for this option, which is off.

The help directive signifies that the rest of the test, indented as it is, is the help text for this entry. The various configuration tools can display this text when requested. Because this text is for users and developers building their own kernels, it can be succinct and to the point. Home users do not typically build kernels and, if they did, they could probably understand the configuration help as is.

There are other options, too. The depends directive specifies options that must be set before this option can be set. If the dependencies are not met, the option is disabled. For example, if you added the directive

depends on FISH_TANK

to the config entry, the module could not be enabled until the CONFIG_FISH_TANK module is enabled.

The select directive is like depends, except it forces the given option on if this option is selected. It should not be used as frequently as depends because it automatically enables other configuration options. Use is as simple as depends:

select BAIT

The configuration option CONFIG_BAIT is automatically enabled when CONFIG_ FISHING_POLE is enabled.

For both select and depends, you can request multiple options via &&. With depends, you can also specify that an option not be enabled by prefixing the option with an exclamation mark. For example,

depends on DUMB_DRIVERS && !NO_FISHING_ALLOWED

specifies that the driver depends on CONFIG_DUMB_DRIVERS being set and CONFIG_NO_ FISHING_ALLOWED being unset.

The TRistate and bool options can be followed by the directive if, which makes the entire option conditional on another configuration option. If the condition is not met, the configuration option is not only disabled but does not even appear in the configuration utilities. For example, the directive

bool "Deep Sea Mode" if OCEAN

instructs the configuration system to display this option only if CONFIG_X86 is set. Presumably, deep sea mode is available only if CONFIG_OCEAN is enabled.

The if directive can also follow the default directive, enforcing the default only if the conditional is met.

The configuration system exports several meta-options to help make configuration easier. The option CONFIG_EMBEDDED is enabled only if the user specified that he or she wishes to see options designed for disabling key features (presumably to save precious memory on embedded systems). The option CONFIG_BROKEN_ON_SMP is used to specify a driver that is not SMP-safe. Normally this option is not set, forcing the user to explicitly acknowledge the brokenness. New drivers, of course, should not use this flag. Finally, the CONFIG_EXPERIMENTAL option is used to flag options that are experimental or otherwise of beta quality. The option defaults to off, again forcing users to explicitly acknowledge the risk before they enable your driver.