Re: Special kernel config include file for DIAGNOSTIC defaults

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, Oct 2, 2014 at 4:29 PM, David Holland <dholland-tech%netbsd.org@localhost> wrote:
> 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 understand this paragraph.

Are you assuming that those who building their own kernel are not
smart enough to find src/sys/a/b/c/xxx.config file from "include
a/b/c/xxx.config"?

> 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.

I don't have any opinions about these.  I can't also understand how
these your ideas conflict with the config split.

You look like intentionally ignoring modularity.  Userland is already
modular (libraries).  Why not kernel too?

You should also consider rump "kernel" and the extendability for 3rd
parties (using kernel modules of course).