Re: config(5) break down

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

On Mon, Mar 15, 2010 at 11:50:09PM +0900, Masao Uebayashi wrote:
> 2010/3/15 Wojciech A. Koszek <wkoszek%freebsd.org@localhost>:
> >        device  X
> >
> > builds device X staticly into the kernel (and maybe does something
> > device-specific), while:
> >
> >        module  X
> >
> > Only builds a KLD. I picked "module", since it seems to be more-or-less an 
> > oposite of:
> >
> >        static  X
> >
> > which could build feature "X", which is not a device" staticly. I think your
> > config(8) has this problem solved somehow, since you seem to have 
> > "filesystem"
> > keyword as well.  Nowadays, given that as you mentioned for NetBSD, in 
> > FreeBSD
> > we also have no scoping for config(8), we must build all KLDs just in case
> > someone needs them, since we don't know which file belongs to which module.
> 
> Who writes these in what file?

Every module has separate Makefile in src/sys/modules/... Isn't it the same in
NetBSD?

> 
> > 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?
> 
> Without looking them, I don't think any infrastructural (== config(1)
> itself) change helps.  Why not fix source code rather than "improving"
> config(1)?

You mean that you have a solution for:

        struct mystruct {
        #ifdef DEBUG_MYSTRUCT
                int      line;
                char    *file;
                char    *func;
                void    *another_pointer;
        #endif
                ...
        };

within a kernel code? That's the simpliest example, of course. There are
areas where you simply can't prevent this kind of #ifdef's.

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