Messages in this thread |  | | Date | Thu, 7 Sep 2000 09:19:21 -0500 | From | Peter Samuelson <> |
| |
[viro] > 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 Config.in 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 Config.in 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 pretty.)
> * Yes, Virginia, it means that controlflow-affecting expansion has to > go. Good riddance, IMO.
IMO too.
Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |