Date: Thu, 14 Aug 2003 22:32:12 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@freebsd.org Cc: current@freebsd.org Subject: Re: Change to kernel+modules build approach Message-ID: <20030814.223212.102654511.imp@bsdimp.com> In-Reply-To: <XFMail.20030814110100.jhb@FreeBSD.org> References: <20030814100248.GB88037@sunbay.com> <XFMail.20030814110100.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <XFMail.20030814110100.jhb@FreeBSD.org>
John Baldwin <jhb@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030814.223212.102654511.imp>