Messages in this thread |  | | Date | Wed, 6 Sep 2000 13:32:52 -0400 (EDT) | From | Alexander Viro <> |
| |
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/
|  |