Re: config(5) break down

["Wojciech A. Koszek" <wkoszek%FreeBSD.org@localhost>]

On Mon, Mar 15, 2010 at 04:57:46PM +0000, Eduardo Horvath 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.
> 
> 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.

Solaris doesn't target particular environments to which the development
of both NetBSD and FreeBSD is directed nowadays in a great extent -- like
embedded environments. So unless you'd propose some really ugly and bizzare
idea for an #ifdef that'd save 3k of bytes from the kernel image size, I 
believe people would go for it.

> 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.)

Well, I don't know about NetBSD, but we aren't there yet.

It's more or less possible right now as long as you'd be loading kernel modules
coming from the same "build" and with the same set of critical options.
Otherwise, if the "struct mutex" changes its size due to #define LOCK_DEBUGGING
in the kernel, you'll going to get a page fault from the module's code with a
useless trace message.

And from the reports that I see, people still use all those extended debugging
features for tracking SMP problems.

For now, this is also the area that can be improved (easily). If every KLD had
an ELF section "CFLAGS" with sort of ASCII strings saying how it was compiled,
kernel could simply prevent its loading.

-- 
Wojciech A. Koszek
wkoszek%FreeBSD.org@localhost
http://FreeBSD.czest.pl/~wkoszek/