[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

> In the .config file, the problem is that the Makefiles source .config
> and then do a lot of "ifdef CONFIG_FOO" tests. There are about 300
> instances of this in 2.4.0-test-7.

Separate issue. We're not talking about emitting n symbols to .config,
or at least I'm not. In this thread.

> In include/linux/autoconf.h, the problem is in the *.c (and *.h and *.S)
> files that do a lot of "#ifdef CONFIG_BAR" and "#if defined(CONFIG_BLETCH)
> tests. There are about 8000 instances of this in 2.4.0-test-7.

I didn't say it would be a *short* transition. I said the above would
all have to become "#if CONFIG_BAR" which is perfectly legal (an
undefined value compares as 0, and Configure #defines things to 1).

> Even worse, any third-party module source is likely to contain the same
> "#ifdef CONFIG_BAR" tests. Changing the definitions of CONFIG_BAR will
> silently break all of them.

Yeah. Long transition, plus user education (which never works, dontcha
know), plus probably a helper tool akin to checkconfig.

> I'm all in favor of 'if ( CONFIG_BAR )', but I think it will have to
> be 'if ( CONFIG_BAR - 0 )' if you want to use them any time soon.

Am I being obtuse? What is the functional difference? I think you
would get a "CONFIG_BAR undeclared (first use this function)" either
way, right?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.039 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site