:: 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>Received on Fri Aug 15 2003 - 13:51:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:18 UTC