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

[Max Laier]

At least since I noticed "Revised kld build infrastructure" on the
5.2-TODO I am wondering about that topic. I'd like to publish what I
have in mind and get some feedback about.

What we have:
=============

1) sys/conf/options and sys/conf/files (and the md equivalents)
describe how a certain option impacts on the kernel build, but fail to
describe dependencies among the particular options.

2) Quite a few options are used to conditionally compile hooks- and
glue-code which might be necessary for a certain module to work.

3) #include "opt_xxx.h" describes dependencies already, but isn't used
consequently enough to really base a decision on.

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.

Pros:
=====

1) Introducing said labels will help to understand the code and it's
dependencies better. In addition it will enable automated tools to
understand dependencies and act on them. For example it will be
possible to build a much smarter tinderbox that does not only build as
much code as possible, but can - in addition - link as _few_ code as
should be possible and thus discover missing #ifdef's and dependencies
that shouldn't exist.

2) The code will be much more manageable as you can easily query the
meaning of a given source file, the subsystem it is part of and the
shoulders it stands on. (The earlier two can already be guessed from
the path and name, but it is tricky sometimes).

3) (Graphical-)UIs: One could use the information to build quite a few
useful tools to manage code and builds. Reaching from linux-like gtk
kernel config (~ugh~) to information-rich tree representations of the
kernel and it's symbols (debug helpers).

4) Better understanding of new and contributed code. If you chooses to
sync a new subsystem from another OS you will come across the sys/conf
stuff in a relative early stage of your porting (at least the way I
port things). With the new system you will be asked to really define
the stuff you bring as well as it's dependencies.

Special case(s):
==============

1) There are three sorts of options right now:
   a) "Subsystem options", which define a whole class of symbols and
      hookcode. e.g. INET
   b) "Additional code". This applies to drivers as well as to pseudo-
      devices. Most of these can be built as a module.
   c) "Real options", which change the behaviour of all code. e.g.
      INVARIANTS.
   While a) and b) are well described on a per-file basis, c) has to
   be handled in a different/special way.

Cons:
=====

1) It's a lot of work, but I am set doing it.
2) Build-tools need to be rewritten, though the most can be handled by
   Makefile-magic, sed/awk and friends - I think.
3) You tell me ...

Okay, that got a bit longish already. I hope I did make some points
and you understand them.

To clarify: I am going to look into this closer from now, but want
some of your thoughts and critics to know if I am heading into the
right direction. As you might have guessed from the examples and my
other writings, I am quite familiar with the net-stuff - full stop.
That means I don't know if the suggested is sufficient for other parts
of the kernel, so tell me!

-- 
Best regards,
 Max                          mailto:max at xxxxxxxxxxxxxx