[ section.
There's also an explanation about ``historic'' and ``new-style''
options. The ultimate goal is to eventually turn all the supported
options in the kernel into new-style ones, so for people who
correctly did a Basically, a kernel option is nothing else than the definition of
a C preprocessor macro for the kernel compilation process. To make
the build truly optional, the corresponding part of the kernel
source (or kernel
#ifndef THIS_OPTION
#define THIS_OPTION (some_default_value)
#endif /* THIS_OPTION */
]This way, an administrator mentioning another value for the
option in his config file will take the default out of effect, and
replace it with his new value. Apparently, the new value will be
substituted into the source code during the preprocessor run, so it
must be a valid C expression in whatever context the default value
would have been used.
It is also possible to create value-less options that simply
enable or disable a particular piece of code by embracing it in
#ifdef THAT_OPTION
[your code here]
#endif
Simply mentioning People familiar with the C language will immediately recognize
that everything could be counted as a ``config option'' where
there is at least a single
options notyet,notdef
in their config file however, and watch the kernel compilation
fall over. :-)
Apparently, using arbitrary names for the options makes it very
hard to track their usage throughout the kernel source tree. That is
the rationale behind the opt_foo.h.
This way, the usual Makefile dependencies could be applied, and
The old-style option mechanism still has one advantage for local
options or maybe experimental options that have a short anticipated
lifetime: since it is easy to add a new Now what do I have to do for it?
First, edit sys/conf/options (or
sys/i386/conf/options.<arch>, e. g.
sys/i386/conf/options.i386), and select an
opt_foo.h file where your new option would best go
into.
If there is already something that comes close to the purpose of
the new option, pick this. For example, options modifying the
overall behaviour of the SCSI subsystem can go into If there is no opt_foo.h already available for
the intended new option, invent a new name. Make it meaningful, and
comment the new section in the
options[.<arch>] file. Packing too many options into a single
opt_foo.h will cause too many kernel files to be
rebuilt when one of the options has been changed in the config file.
Finally, find out which kernel files depend on the new option.
Unless you have just invented your option, and it does not exist
anywhere yet,
find /usr/src/sys -name type f | xargs fgrep NEW_OPTION
is your friend in finding them. Go and edit all those files, and
add
#include "opt_foo.h"
on top, before all the
#ifndef NEW_OPTION
#define NEW_OPTION (something)
#endif
in the regular header.
Adding an option that overrides something in a system header file
(i. e., a file sitting in /usr/include/sys/) is almost
always a mistake. opt_foo.h cannot be included
into those files since it would break the headers more seriously,
but if it is not included, then places that include it may get an
inconsistent value for the option. Yes, there are precedents for
this right now, but that does not make them more correct.