Re: Special kernel config include file for DIAGNOSTIC defaults

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Sep 30, 2014 at 07:07:26PM -0400, Greg Troxel wrote:
 > > [...]
 > 
 > That sounds good.   It's perhaps like filesystems.config.

Which, as I said on source-changes-d, I'm not sure is the right way to
do that.

 > [...] This is
 > really heading down the path of deconstructing the standard config into
 > pieces that can be included differently.

Right.

Traditionally GENERIC serves at least two purposes beyond just
configuring a kernel: it is a starting point for copying and then
cutting down when making your own config, or serves as reference
syntax copying sections or entries from; and also it documents which
drivers exist and which are believed to be stable.

Any new scheme should be planned out (not backed into by a series of
minor least-difficulty changes) and should be arranged so it preserves
these additional purposes.

Splitting off chunks into miscellaneous include files with not
terribly obvious names, especially when they're (necessarily) in a
different directory, is bad on both alternate purposes.

I don't have a scheme in mind (perhaps surprisingly, I usually have at
least *something* in mind for any reorg or redesign, even if it's
lame) but in the absence of other bright ideas, I think we should
strongly consider having only one of these MI include files and
calling it src/sys/conf/GENERIC.MI, because then it's easily seen and
easily recognized for what it is.

Some other things to at least think about:

   - making src/sys/conf the place we config kernels from (and
     therefore, presumably, src/sys/compile the place we build them)
     and making the MD parts the include files, even though this is a
     big departure;

   - adding syntax to config to support explicit conditional blocks,
     so include files like GENERIC.MI can turn on and off whole lists
     of things based on single, easily-settable options;

   - adding options of enumerated type to config, so for example you
     might start a custom x86 config with "options X86_GENERATION=PIII"
     to get a sensible default list of drivers, but if you set it to
     FROBNITZ it fails instead of behaving uselessly;

   - adding a way to turn on and off whole subtrees of the device
     hierarchy, to allow e.g. "disable usb" without having to
     explicitly also turn off all the devices that attach to usb;

   - adding other syntax or features to config to make all this
     easier, although I'm not sure what.

-- 
David A. Holland
dholland%netbsd.org@localhost