There is a long-standing problem that occasionally causes grief because
some kernel code that checks for kernel options (eg MULTIPROCESSOR or
LOCKDEBUG) but don't actually include the corresponding opt_*.h file.

There is also to inverted issue that a lot of the source files get compiled
with some of the opt_*.h files, even though they don't actually depend
on the option itself [1].

If we can reduce the number of opt_*.h files included in each compilation,
it ought to be possible to define absolute symbols in the object file with
the name and value of the option, and then use these to detrmine whether
two different kernel can share the same binary (as well as stopping you
linking kernels built with components compiled with different values for
the same option).

Unfortunately the only files that currently build with the same options
are GENERIC and GENERIC.DIAGNOSTIC - which are different! (gets passed
as -DDIAGNOSTIC, not via an opt_*.h file).

However I don't really want to start removing '#include "opt_foo.h"' from
kernel header files until the build auto-detects failure to include
the relevant opt_foo.h file.

At the moment, config(1) generates opt_foo.h file that contain either:
	#define FOO value
or:
	/* option `FOO' not defined */
where 'value' is the text that follows the = sign in the kernel CONFIG file,
or 1 if no value is specified.
Code typically uses '#ifdef FOO' to inspect the config value.
If opt_foo.h isn't included, the answer is always 'false'.

In order to generate a compile time error, I propose changing config
to generate:
	#define FOO() value
setting value' to zero [2] if the option is disabled.

Code will then have to contain '#if FOO()' which generated a syntax error
if opt_foo.h isn't defined.

Any other thoughts/objections before I try to script the required edit?
Separating the 'option configured' from the 'option enabled' by having
two #defines would make any automated edit completely impossible.

I might also change the defines to be KERNEL_OPT_FOO at the same time.

	David

[1] An extreme example of this is the i386 option 'MATH_EMULATE' which adds
a small amount of code to the trap handler (and an extra file), but is
defined in almost every source file because src/sys/arch/i386/include/cpu.h
includes it solely to protect a function prototype.

[2] Actually there are a small number of options where the default is
'enabled' and the kernel config files may contain 'options FOO=0' to
turn the feature off.  This is probably best 'fixed' by allowing a default
value to be specified when the option is defined (eg in sys/conf/files),
say by specifying 'defflag FOO=1' or 'defparam FOO=1'.

-- 
David Laight: david@l8s.co.uk