From owner-freebsd-current@FreeBSD.ORG Fri Aug 15 11:24:20 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 785C437B401; Fri, 15 Aug 2003 11:24:20 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A262A43F85; Fri, 15 Aug 2003 11:24:19 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h7FIO4FL030217; Fri, 15 Aug 2003 12:24:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 15 Aug 2003 12:27:00 -0600 (MDT) Message-Id: <20030815.122700.124829872.imp@bsdimp.com> To: gallatin@cs.duke.edu From: "M. Warner Losh" In-Reply-To: <16189.7417.798216.977283@grasshopper.cs.duke.edu> References: <20030814.224014.08945805.imp@bsdimp.com> <16189.7417.798216.977283@grasshopper.cs.duke.edu> X-Mailer: Mew version 2.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: lchen@briontech.com cc: current@freebsd.org Subject: Re: Change to kernel+modules build approach X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 18:24:20 -0000 In message: <16189.7417.798216.977283@grasshopper.cs.duke.edu> Andrew Gallatin 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