Date: Fri, 15 Aug 2003 12:27:00 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: gallatin@cs.duke.edu Cc: current@freebsd.org Subject: Re: Change to kernel+modules build approach Message-ID: <20030815.122700.124829872.imp@bsdimp.com> In-Reply-To: <16189.7417.798216.977283@grasshopper.cs.duke.edu> References: <20030814.224014.08945805.imp@bsdimp.com> <XFMail.20030815134026.jhb@FreeBSD.org> <16189.7417.798216.977283@grasshopper.cs.duke.edu>
index | next in thread | previous in thread | raw e-mail
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).
Warner
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030815.122700.124829872.imp>