public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
To: David Miller <davem@davemloft.net>
Cc: rweikusat@mobileactivedefense.com, adobriyan@gmail.com,
	kaber@trash.net, netfilter-devel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c
Date: Mon, 18 Jul 2011 21:17:00 +0100	[thread overview]
Message-ID: <87d3h7e43n.fsf@sapphire.mobileactivedefense.com> (raw)
In-Reply-To: <20110718.124638.30010338187296272.davem@davemloft.net> (David Miller's message of "Mon\, 18 Jul 2011 12\:46\:38 -0700 \(PDT\)")

David Miller <davem@davemloft.net> writes:
> From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
> 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'.

  reply	other threads:[~2011-07-18 20:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01 14:44 [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c Rainer Weikusat
2011-07-18 16:21 ` Patrick McHardy
2011-07-18 17:56   ` Rainer Weikusat
2011-07-18 19:11     ` Rainer Weikusat
2011-07-18 19:19     ` Alexey Dobriyan
2011-07-18 19:43       ` Rainer Weikusat
2011-07-18 19:46         ` David Miller
2011-07-18 20:17           ` Rainer Weikusat [this message]
2011-07-18 20:19             ` David Miller
2011-07-18 20:32               ` Alexey Dobriyan
2011-07-19  9:42                 ` Patrick McHardy
2011-07-18 20:27             ` Eric Dumazet
2011-07-18 20:28             ` Jan Engelhardt
2011-07-19 21:38               ` Rainer Weikusat
2011-07-20 15:04                 ` [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c (updated) Rainer Weikusat
2011-07-26 11:22                   ` Rainer Weikusat
2011-07-26 11:37                   ` [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c (updated again) Rainer Weikusat
2011-07-28  7:00                     ` Patrick McHardy
2011-07-28 19:56                       ` Rainer Weikusat
2011-07-28 19:57                     ` [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c (updated yet again) Rainer Weikusat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d3h7e43n.fsf@sapphire.mobileactivedefense.com \
    --to=rweikusat@mobileactivedefense.com \
    --cc=adobriyan@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox