This source-changes mail reminded me of something I have been meaning to
suggest for a while...

	Add dependencies on Makefile for  SYSVSHM, SYSVIPC options.

Nothing wrong with that change as such of course - what's wrong is the
need for it, the way BSD has done kernel options (since day 1) is dumb.

Back in the 4.2 days (or thereabouts) I actually fixed that, but never
got around to retuning the changes to Berkeley - at the time their kernels
were changing so quickly that it would have been a whole bunch of extra work
(and I have always hated extra work).

Having the options implemented via -D args in CFLAGS in the Makefile,
requires that the .c files that use the options (and worse, any .c files
that include any .h files that use the options) have dependencies on Makefile
inserted, and since all this is beyond (way beyond) the capacity of mkdep,
they need to be done manually - and as dependancies only matter when the
values change, developers who often don't change their options easily forget
to add the things.

Options should be handled just the same way as device drivers, handled via
generated include files, which mkdep can then easily find, and which also
have the (less important) side effect of requiring recompiling only what
really needs to be recompiled after anything which changes the Makefile.

Get this right and the annoying "remove everything and config and compile
again" nonsense way of fixing problems should also be a thing of the past.

There are lots of ways this could be done - the only tricky part is arranging
things so that config doesn't have to know every option that exists.   The way
I would do that now (a little different than I remember from last time, many
years ago), would be to create an "options" directory as a sibling of
kern sys include ...  (if needed, there could also be arch/*/options 
directories - haven't thought about that one, when I did it there was just
one arch.)    In that goes an include file for each option, named after the
option (so from the above, SYSVSHM.h and SYSVIPC.h - those can be converted
to lower case for appearances if desired).   In those include files are
whatever #defines that are needed to cause the options to be set at their
default values (off for most of them)..

Then, each .c (or .h) file that uses an option, has included in its prolog

	#include "options/OPTION.h"

for the relevant option(s).

Then, config(8) needs to be modified so as to make a compile/SYSTEM/options
directory, copy everything from the options (and arch/xxx/options if those
directories are needed, and the relevant one exists) into compile/SYSTEM/options
and then, for each "option FOOBAR" in the config file, replace the
compile/SYSTEM/options/FOOBAR.h with a version that has the #define replaced
with one that has the appropriate value (the same thing which would be placed
on the -D CFLAGS entry now, or '1' if there would be none, mimicing cpp).

Config actually needs a bit of bookkeeping to make sure that it replaces
options/FOOBAR.h files with the "off" version whenever the option is removed
from the config file, without causing all of the files to be touched every
time config is run to make a minor change.

For a simplisitc implementation, the upper level options directory is
really just providing config with a list of the options (which it gets
by reading the directory) - clearly a file containing the same list would
work just as well.   However, with the directory, the .h files included can
contain more than just the one #define line each that a minimal implementation
would require - obviously, they could contain comments describing the options,
which would make it easy for people to find what options exist, and when
they ought be used.    But more than that, they can also contain the necessary
conditions to force whatever interdependancies should exist between the
options (can't have this unless you also have ...).   If config(8) is smart
in the way it updates the files, leaving all alone but the one line with
the #define (or #undef for off options) and simply copying the rest verbatim
then all this is fairly easy to get right.

Finally, the extra advantage that comes from this is that config can complain
when the user mis-types an option, and instead of including a useless
-Dspelling_mistake in the Makefile, actually warn the user that the kernel
being compiled has no such option, and that perhaps either the option line
should be removed (if it is an old option now obsoleted), or the typo be
fixed.

Anyway, this is just something for the relevant people to think about
sometime when they have nothing better to do...

kre