[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100820134314.GA3283@Krystal>
Date: Fri, 20 Aug 2010 09:43:14 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To: Changli Gao <xiaosuo@...il.com>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Patrick McHardy <kaber@...sh.net>,
"David S. Miller" <davem@...emloft.net>,
netfilter-devel@...r.kernel.org, netdev@...r.kernel.org,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] netfilter: save the hash of the tuple in the
original direction for latter use
[ executive summary: trying to explain why static variable declarations
within the body of functions is bad in kernel code. ]
* Changli Gao (xiaosuo@...il.com) wrote:
> On Fri, Aug 20, 2010 at 12:11 AM, Mathieu Desnoyers
> <mathieu.desnoyers@...ymtl.ca> wrote:
> >
> > Ah, I see. But I think the static variable should stay declared outside
> > of the function scope, with a nice comment explaining why it's not
> > initialized at init-time.
> >
> > Hiding global state in function code is usually frowned upon.
> >
>
> I don't agree with you. We'd better not expose the variable which
> isn't expected to be used by others. If not, maybe someone will misuse
> it.
We are talking about a static variable usable only within a single file,
where is the problem ? A nice comment can have this effect.
> The user should only reply on the interface, but not the internal
> implementation.
I'm talking about good practice to help code review. This is way more
important than the potential "encapsulation" benefit of hiding global
state (a static variable) within the body of a function.
I remember that Andrew Morton has strong opinions about this, and I
remember being in complete agreement with him on the topic.
Thanks,
Mathieu
>
> Thanks.
>
> --
> Regards,
> Changli Gao(xiaosuo@...il.com)
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists