Re: Thoughts about: modules- and kernelbuild, sys/conf revised

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:What I want:
:============
:
:1) Every .c file in the sys directory should have a label that
:describes - in a parseable way - what this file (and the contained
:objects) are good for and which options impact the compilation.
:
:2) These labels could be defined in a reworked sys/conf "database"
:or/and by special per-file comments (like rc-NG does).
:
:3) There should be a way (sysctl, ident or alike) to query the kernel
:for built-in hooks and glue, to decided what modules can work with it
:and how to configure the build. e.g. INET/INET6
:3a) Modules build with the kernel should of course be configured to
:really match the kernel.

    Well, the biggest problem with formalizing the build infrastructure
    to this degree is that you are hitting diminishing returns in regards
    to ease of use and integration issues.

    At the moment we are on a slow path to modularizing a good chunk of the
    system.  Nearly all the kernel modules that can be statically linked
    into the kernel are also built as separate modules and the loader 
    (especially the new loader) can preload them along with the kernel.

    So, theoretically, instead of having a build architecture which
    statically links modules into the kernel would could instead build
    them separately and then do a final 'ld -r' pass to construct the
    'final' kernel binary which integrates those modules we want to be
    built-in.  And, theoretically, we don't even have to do that... the
    boot loader can pre-load the modules along with the kernel already.

    For safety reasons, however, many sysads (including myself) will always
    want to build-in certain critical modules to guarentee that the kernel
    is able to boot far enough to debug over a network, so we can't rip
    out static linking.

    -

    The modules themselves already have a declarative dependancy
    infrastructure through the use of the DECLARE_MODULE() and
    MODULE_DEPEND() macros, and in fact the kernel loader already
    uses these dependancies to a degree.  This infrastructure
    could theoretically be used to manage module configurations but,
    again, one quickly hits diminishing returns.  It just isn't all
    that useful to construct a topology visible to a GUI based user
    config utility when nearly all the modules in question can be
    auto-detected by either the kernel or (through ACPI) the loader.

    I think what would be more useful would be a formalization of PCI IDs
    and other declarative information required to allow the kernel and/or
    utilities to build a database automatically and match kernel modules 
    against hardware automatically.  That would be very cool.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>