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

> 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

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