Re: x86 GENERIC kernels unlobotomized

[David Laight <david%l8s.co.uk@localhost>]

On Wed, Aug 10, 2011 at 12:01:55PM +0200, Manuel Bouyer wrote:
> 
> It's one of the issue with this scheme. For example you compile a kernel
> with options DEBUG, but the modules are not ... If modules were part
> of the kernel build they could inherit the options
> (this is true for compile flags as well).

I've played around (can't remember if I actually committed it) with
putting global constants into kernel .o files for build options.
I didn't do DEBUG and DIAGNOSTIC because they come from -Dxxx
not opt_xxx.h, but they could be added from a standard header.
This could be used to stop modules with the wrong value constant
being loaded...

The other thought about kernel builds is to do the following:
- add the definition and makeup of 'modules' to 'configure'
- build the base kernel to netbsd.o and all the modules
- link some of the built modules with kernel.o to generate a set of
  'useful' kernels.

This would mean that the kernels could share modules.
It should also make easier to stop a module being loaded when the
functionality is already linked into the kernel.

Of course, some options change the way things are build, not just
which files are included in a kernel.  IMHO they should largely be removed.

Just need that big pile of tuits.


        David

-- 
David Laight: david%l8s.co.uk@localhost