From owner-freebsd-current@FreeBSD.ORG Fri Aug 15 12:29:32 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 9728737B401 for ; Fri, 15 Aug 2003 12:29:32 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A41F43FB1 for ; Fri, 15 Aug 2003 12:29:31 -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 h7FJTGFL030825; Fri, 15 Aug 2003 13:29:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 15 Aug 2003 13:35:38 -0600 (MDT) Message-Id: <20030815.133538.89662402.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: References: <20030815.122700.124829872.imp@bsdimp.com> 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: gallatin@cs.duke.edu 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 19:29:32 -0000 In message: Julian Elischer writes: : : : On Fri, 15 Aug 2003, M. Warner Losh wrote: : : > 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). : : 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