Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

From: Peter Samuelson (
Date: Thu Sep 07 2000 - 09:19:21 EST

> The _real_ problem is preprocessor abuse. BTW, could we schedule for
> 2.5 the following?
> * things like CONFIG_FOO are _always_ defined. As 0 or 1, that is.
> * #ifdef CONFIG_FOO => if (CONFIG_FOO) in *.c. gcc will kill the unused
> branches just fine.

Notwithstanding the string literal gcc bug already mentioned....

It's non-trivial at the kernel config stage. As in, a rewrite of
config and menuconfig (might be easier for xconfig). Because currently
they leverage bash parsing and control flow, so parts of
files are not seen by Configure/Menuconfig proper. So some of the
#define CONFIG_X 0 can't happen, with current design.

It's really the same problem you're complaining about, all over again.
bash acts as the preprocessor here. Not that most of us particularly
like the bash-parsing implementations currently in use, but there they
are. If and when esr's new config stuff is adopted this sort of thing
will be *much* easier to add cleanly.

Actually, hackery would be possible -- have a stage of `make config'
that basically greps all files for words CONFIG_* and makes
sure they are all #defined, one way or another. Hackery is hackery,
though there's already a lot of it in the kbuild system.

Migration strategy:
1. s/#ifdef/#if/ all over the kernel (for CONFIG_* only of course --
   other macros aren't guaranteed to evaluate to true).
2. Play with kbuild until you get the 1's and 0's.
3. Start putting the real C control flow in.

I will do the step 2 hackery, if you want. (As I said it won't be

> * Yes, Virginia, it means that controlflow-affecting expansion has to
> go. Good riddance, IMO.

IMO too.

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

This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:29 EST