tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: config(5) break down



On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote:
> 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.

I think it is also for narrowing the impact of particular options; it tends to
act as a sort of layering and encapsulation. And saves a bit of confusion when
a commiter enabled his debugging facility with DEBUG, which may not be unique.

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

You mean that the delivery of two versions of each kernel module could 
eventually
solve the problem for you?

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


Home | Main Index | Thread Index | Old Index