Change to kernel+modules build approach
Matthew Dillon
dillon at apollo.backplane.com
Fri Aug 15 15:51:22 PDT 2003
:: Has anyone in this discussion looked at what Matt has done with
:: Dragonfly? He's re-arranged the kernel tree and moved each driver/module
:: into its own directory. Each directory has a Makefile. thus
:: a traversal of the kernel tree "make" hierarchy generates the modules.
::
:: The "modules" subdirectory is going away.. (I think he's in the middle
:: of doing that now)
:
:That's certainly an interesting concept. One that would make it
:easier to deal with modules since you have the Makefile right where
:you need it. If that is all that he's done, then that wouldn't answer
:John's objection to the current state of affairs: meta data in two
:places (module Makefile and conf/files*). If he's done something
:else in addition to the movement, then that would be interesting to
:look at.
:
:Warner
Yes, I've done away with the 'modules' directory and have been
reincorporating the modules Makefiles into the main part of the kernel
tree.
It turns out not to be all that difficult. Most module Makefile's can
be plopped into the proper directory with very few changes. On half of
them I only had to remove the .PATH directive. Subdirectories are glued
together with the standard bsd.subdir.mk.
Some surgery is required, but nothing difficult. For example, the
netgraph modules necessitated moving each /usr/src/sys/netgraph/*
element into a subdirectory to accomodate the Makefile for that
netgraph module. There are a few areas like that... mainly changes
which force partitionable entities into their own subdirectories which
I consider to be good for the structure of the system.
It is still a work in progress but I am very close to getting all the
ducks honking properly in regards to config based kernel builds,
make buildkernel, separate module builds, and module builds with and
without 'make obj'. I heartily recommend that -current investigate
and implement the refolding of the module build into the main kernel
source tree.
Eventually my goal is to make the entire kernel sufficiently modular
that 'config' can be gotten rid of (or, at least, relegated to just
generating the various .h files from the config options).
--
I have also done additional (and very extensive) reorganization of the
kernel source tree, but it is probably too extensive for -current to
consider (read: about 40 dillon hours of work plus another 40 dillon
hours to cleanup the build issues afterwords). Not only did I completely
reorganize filesystems, network subsystems, and device drivers,
I also moved driver-specific architecture-specific files out of e.g. i386/
and into <appropriate_driver>/i386, and I also changed config to
generate use_*.h instead *.h files, which allowed me to remove the -I-
sillyness from the Makefiles, which in turn allows relative #include
file paths to be used again in the kernel source (in the many places
where they make sense, which is just about everywhere). This greatly
improves our ability to modularize of the kernel.
But it was a huge amount of work. If I were to pick *one* thing to
recommend that -current adopt it would be to change all the config
generated *.h files to use_*.h (plus the same thing in those module
makefiles which generated *.h files), and get rid of the -I- compiler
option, then incrementally fix all the #include's that can be trivially
relative to being trivially relative.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the freebsd-current
mailing list