From owner-freebsd-current@FreeBSD.ORG Fri Aug 15 11:52:05 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 8397937B401 for ; Fri, 15 Aug 2003 11:52:05 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E3FD43FD7 for ; Fri, 15 Aug 2003 11:52:05 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc13) with ESMTP id <2003081518520401500gka6qe>; Fri, 15 Aug 2003 18:52:04 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA12580; Fri, 15 Aug 2003 11:52:03 -0700 (PDT) Date: Fri, 15 Aug 2003 11:52:02 -0700 (PDT) From: Julian Elischer To: "M. Warner Losh" In-Reply-To: <20030815.122700.124829872.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 18:52:05 -0000 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) > > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >