21.2. Now What Do I Have to Do for it?

First, edit sys/conf/options (or sys/<arch>/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 behavior 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 -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.

For questions about FreeBSD, e-mail <questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.