Change to kernel+modules build approach

[Andrew Gallatin]

John Baldwin writes:
 > 
 > On 14-Aug-2003 Andrew Gallatin wrote:
 > > 
 > > 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.
 > > 
 > > Would this tie modules to that kernel config?  If so, would it mean
 > > the end of the ability of 3rd party developers to ship binary drivers
 > > and expect them to work with any kernel?
 > 
 > Well, yes, but, one could always build generic modules by using
 > a kernel config containing 'options KLD_MODULE' or some such.
 > This would allow one to compile optimized modules if they wanted to,
 > but still provide the ability to build fully generic modules.

My concern is that if we do such a thing, we'll gradually gain more 
options which break modules.  Right now, the list includes
MUTEX_PROFILING and PAE.   I'm afraid it can only grow if modules
are further coupled with the kernel build.

Drew