On Tue, Mar 16, 2010 at 06:55:36AM +0900, Masao Uebayashi wrote: > On Tue, Mar 16, 2010 at 1:57 AM, Eduardo Horvath <e...@netbsd.org> 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 wkos...@freebsd.org http://FreeBSD.czest.pl/~wkoszek/
