From owner-freebsd-current@FreeBSD.ORG Thu Aug 14 21:46:55 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 7768C37B401; Thu, 14 Aug 2003 21:46:55 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9324C43F75; Thu, 14 Aug 2003 21:46:54 -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 h7F4kIFM024677; Thu, 14 Aug 2003 22:46:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 14 Aug 2003 22:32:12 -0600 (MDT) Message-Id: <20030814.223212.102654511.imp@bsdimp.com> To: jhb@freebsd.org From: "M. Warner Losh" In-Reply-To: References: <20030814100248.GB88037@sunbay.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: 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 04:46:55 -0000 In message: John Baldwin writes: : : On 14-Aug-2003 Ruslan Ermilov wrote: : > On Thu, Aug 14, 2003 at 02:10:19AM -0600, Scott Long wrote: : >> Luoqi Chen wrote: : > [...] : >> >On the other hand, all modules should create all the opt_*.h files : >> >it needs when built individually. Add opt_ddb.h to nullfs's Makefile : >> >should fix the breakage. : >> > : >> Our kernel build system isn't set up to handle passing config options : >> to modules. Various solutions to this have been proposed, but nothing : >> has appeared yet. In 5.x, we document that modules will not work with : >> PAE. : >> : > How does the below look? This is basically a more generic implementation : > of Luoqi's idea, but for -CURRENT: : : I would prefer something far more radical that would involve moving : all the module metadata to sys/conf (i.e. removing sys/modules) and : building all the modules based on a single kernel config file. Does that mean that we're abandoning the idea that modules will work with all kernels? I don't disagree with the metadata move, since it is duplicated in two places now and allows for some more interesting subsettting, but I'm concerned that our third party ISVs will need to generate N different modules for the system... Warner