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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030815.122700.124829872.imp>