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

    Yes, I've done away with the 'modules' directory and have been
    reincorporating the modules Makefiles into the main part of the kernel

    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.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to