On 6 Sep 2000, Linus Torvalds wrote:
> At the same time, there is no question that true #ifdef's have
> advantages, even outside the issue of gcc's inability to forget literal
> strings. They are often required for data structures in general: C does
> not have "conditional data structures". Certain fields just do not
> exist when SMP is disabled, for example. And we don't _want_ them to
> exist, because they bloat out data structures that we're trying to keep
> reasonably small.
True. But right now we have a heap of CONFIG_FOO and that heap falls into
three parts:
1) stuff that is not used in *.[chS]. At all. CONFIG_EXT2, for
one. Makefiles - yes, but that's basically "what we link" kind of
influence.
2) stuff that _is_ used, but doesn't really have to be #ifdefs
3) tiny group of options that really have to affect the compile
in non-trivial ways. CONFIG_SMP is an obvious example. CONFIG_PROC_FS
_may_ be another, simply due to the amount of instances in the current
code. Architecture is probably one more (even though we could do nicer
here). There may be several other (some networking-related ones may be
candidates).
IWBNI they would be clearly separated and #2 would shrink (some of these
guys should be in #1).
> So I disagree with the notion that we should try to avoid using #ifdefs
> etc completely. But I agree that in many cases you can _locally_ try to
> avoid it, resulting in nicer and more flexible code that also has the
> advantage of making sure it can be parsed regardless of what the
> configuration is.
Oh, we certainly can't completely avoid ifdefs without major braindamage.
But there is a difference between several hundreds of options and a dozen
that decides what would be seen by parser. And even essential ones are, in
many cases, used in uglier ways than they have to.
-
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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:26 EST