David Miller <davem@xxxxxxxxxxxxx> writes: > From: Rainer Weikusat <rweikusat@xxxxxxxxxxxxxxxxxxxxxxx> > Date: Mon, 18 Jul 2011 20:43:30 +0100 > >> [rw@sapphire]~/work/linux-2-6/net/netfilter $find -name '*.c' | xargs grep '^#ifdef' | wc -l >> 239 >> [rw@sapphire]~/work/linux-2-6/net/netfilter $.. >> [rw@sapphire]~/work/linux-2-6/net $find -name '*.c' | xargs grep '^#ifdef' | wc -l >> 1672 > > You've shown nothing. Showing exceptions does not prove that the > general effort has been to keep ifdef crap out of *.c files. I've 'shown' that the networking code contains a fair amount of #ifdefs in .c files. Consequently, 'we did it without' is wrong. At best, 'we would like to do without in future' seems justified. > And every developer or maintainer who says no to ifdefs in *.c files > for new changes is %100 right. Adding new files filled with ifdefs in order to avoid ifdefs in old files in favor of lines-looking-like-code-which-arent seems debatable to me. The same goes for adding unused structure members, uneeded function calls, indirections through fifteen different other files that turn out to do nothing etc. I spend much more time trying to read Linux code than to write Linux code and while I decidedly know worse things, Linux isn't exactly a prime example of easily accessible code precisely because so much of it is something completely different than what it appears to be. But this is actually a digression that is besides the point: Put something like 'ifdefs must not be used in new code, no matter what' plainly into the CodingStyle text, then you can expect other people to stick to this convention in the same way as to all the others (or at least try to stick to it). > We're also specifically talking about namespace stuff, so you should have > at least refined your match criteria just a little bit. The person I was replying to wrote 'We did whole networking without sprinkling ifdefs'. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
