Re: config(5) break down

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

2010/3/16 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.

As others said, just don't do that.  You can't fix wrong code by
improving config...

Masao