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