Date: Fri, 15 Aug 2003 13:35:38 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: julian@elischer.org Cc: current@freebsd.org Subject: Re: Change to kernel+modules build approach Message-ID: <20030815.133538.89662402.imp@bsdimp.com> In-Reply-To: <Pine.BSF.4.21.0308151149410.11688-100000@InterJet.elischer.org> References: <20030815.122700.124829872.imp@bsdimp.com> <Pine.BSF.4.21.0308151149410.11688-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <Pine.BSF.4.21.0308151149410.11688-100000@InterJet.elischer.org>
Julian Elischer <julian@elischer.org> writes:
:
:
: On Fri, 15 Aug 2003, M. Warner Losh wrote:
:
: > In message: <16189.7417.798216.977283@grasshopper.cs.duke.edu>
: > Andrew Gallatin <gallatin@cs.duke.edu> writes:
: > :
: > : John Baldwin writes:
: > : >
: > : > No, generic modules would always work with all kernels except for
: > : > exceptional cases like PAE (unavoidable, really), and MUTEX_PROFILING
: > : > (this is a debugging thing, so ISV's wouldn't need to ship modules
: > : > with that turned on). All this would add is the ability to build
: > : > modules optimized for your current kernel. If this is not super
: > : > desired (which I wouldn't mind), then I think we should take the
: > : > modules out of /boot/kernel and put them in /boot/modules or some such.
: > : > I do want to get the metadata down to one copy somehow though.
: > :
: > : YES! YES! I'd be very much in favor of totally decoupling the
: > : modules from the kernel.
: > :
: > : In fact, once we've done that, we can move the kernel back to /kernel
: > : where it belongs, and /boot/modules can become /modules ;)
: >
: > That would be somewhat difficult. It would make it a lot harder to
: > keep a 2 or 4 week old kernel around for testing since you couldn't
: > load current modules with an old kernel (generally, but sometimes it
: > works).
:
: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030815.133538.89662402.imp>