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 opt_scsi.h
.
By default, simply mentioning an option in the appropriate option
file, say FOO
, implies its value will go into the
corresponding file opt_foo.h
. This can be overridden on the
right-hand side of a rule by specifying another filename.
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. config(8)
will
automagically pick up the change, and create that file next time it
is run. Most options should go in a header file by themselves..
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 #include <xxx.h>
stuff. This sequence is most important as the options could
override defaults from the regular include files, if the
defaults are of the form
#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.