Re: config(5) break down

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath <eeh%netbsd.org@localhost> 
wrote:
> On Sun, 14 Mar 2010, Wojciech A. Koszek wrote:
>
>> I was wondering how does Linux/Solaris kernel build system work in terms of
>> opt_*.h files?  Do they have some alternative solutions for #ifdef's based on
>> what has been included into the kernel at configuration time?
>
> It's been a while since I poked around with Linux, but I think they have a
> single file that contains all that info.

My understanding is splitting opt_*.h into small files is just only to
save rebuild time.  Is this right?  It's also same as GNU Autoconf +
configure + #include "config.h" do.

> Solaris has no config.  Period.
>
> You don't have any opt_*.h files.  And you don't really need them.  It's a
> fully dynamic kernel so the only things you can set are things like DEBUG
> and LOCKDEBUG.  You don't worry about including specific modules, because
> they are all compiled separately and loaded on demand.  Loading of modules
> is driven by config files in /etc that define what module is responsible
> for a specific device type (e.g. a specific PCI vendor and device ID
> combination.)  Of course, if those config files get corrupted then the
> machine is unbootable.  To recover you must boot from install media and
> likely reinstall the OS.

Ah.  Thanks for explaining this.  This is pretty much expected.

And this is what NetBSD should not be, IMO, because
- one of NetBSD's targets is highly customized embedded purposes
  - let users customize as they want
    - NetBSD is free, unlike QNX.
    - "users are not stupid"
    - but those customized binaries are not supported

> And since everything is compiled separately you can often just replace one
> module with another one that is compiled with DEBUG turned on.
> Without rebooting the machine.  (Certain inter-module interfaces are
> affected by DEBUG while others are not.  YMMV.)

Thanks, and this is also pretty much expected too.  IIRC Windows did
similar thing; providing foo.dll & foodbg.dll.  I think this strategy
(== providing normal+debug binaries as official module binaries) would
work for us too.

Masao