DragonFly kernel List (threaded) for 2003-11
Re: Thoughts about: modules- and kernelbuild, sys/conf revised
: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.