From: Eric Dumazet <dada1@cosmosbay.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH v2] net: #ifdef inet_bind_bucket::ib_net
Date: Wed, 12 Nov 2008 11:50:29 +0100 [thread overview]
Message-ID: <491AB4F5.2070206@cosmosbay.com> (raw)
In-Reply-To: <20081112104439.GA4292@x200.localdomain>
Alexey Dobriyan a écrit :
> On Tue, Nov 11, 2008 at 04:45:54PM -0800, David Miller wrote:
>> From: Alexey Dobriyan <adobriyan@gmail.com>
>> Date: Tue, 11 Nov 2008 14:19:46 +0300
>>
>>> @@ -35,7 +35,9 @@ struct inet_bind_bucket *inet_bind_bucket_create(struct kmem_cache *cachep,
>>> struct inet_bind_bucket *tb = kmem_cache_alloc(cachep, GFP_ATOMIC);
>>>
>>> if (tb != NULL) {
>>> +#ifdef CONFIG_NET_NS
>>> tb->ib_net = hold_net(net);
>>> +#endif
>>> tb->port = snum;
>>> tb->fastreuse = 0;
>>> INIT_HLIST_HEAD(&tb->owners);
>> No, this is exactly what we don't want.
>>
>> If you have to add ifdefs to core C files, you're doing something
>> wrong.
>
> It depends.
>
>> All the details of ifdef this or ifdef that should be hidden in the
>> header files.
>
> It depends.
>
>> You cited an example where there are a ton of ifdefs in some header
>> fule inline function, but that is EXACTLY how this stuff should be
>> done. Those header files are where such ugly implementation details
>> belong.
>>
>> When people read actual code, they should be concerning themselves
>> with control flow, what the code is trying to do, etc. rather then
>> being continually interrupted with ifdef this and ifdef that.
>
> On the other hand, people are interrupted with ctags jumping when suddenly
> whole new file appears, so loss of context is even more. Distance between
> static inline pair tend to increase as people add more stuff in between.
>
> And how this one line ifdef (in one place -- allocation) can interrupt
> control flow when you see it's start and immediately see it's end? Is it
> because ifdef starts at column one, and code on average is two-three tabs
> indented, so eye jumps to column one?
>
> Whey you are suspicious of the code (say, look for a bug) these wrappers
> are nuisaince, because some very smart one may do completely unexpected
> thing wrt it's innocent name. And you check them all because you're
> suspicious.
>
> Netdevices use dev_net_set(). Add ib_net_set() and forget about this hungarian
> pnet thing. const qualifier is also pointless, there maybe nothing wrong with
> it, be there is nothing right as well.
>
> Well, yes, Linus starts blogging and hungarian notation in core networking. :-)
Take a look at include/net/net_namespace.h
I made my best to choose a notation and found :
copy_net_ns(), __put_net(), net_alive(), get_net(), maybe_get_net(),
put_net(), net_eq(), hold_net(), release_net()
What a mess.
I then decided to name my two helpers read_pnet() and write_pnet(), not
because I love hungarion notaion, but to keep existing practice in this
file.
I have no problem to clean the whole file and have a consistent notation.
I have no problem you take care of this.
Thank you
next prev parent reply other threads:[~2008-11-12 10:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-07 15:44 [PATCH] net: introduce read_pnet() and write_pnet() functions Eric Dumazet
2008-11-07 17:41 ` Alexey Dobriyan
2008-11-07 17:49 ` Eric Dumazet
2008-11-07 18:07 ` Alexey Dobriyan
2008-11-11 0:44 ` David Miller
2008-11-11 11:08 ` [PATCH] net: #ifdef inet_bind_bucket::ib_net Alexey Dobriyan
2008-11-11 11:19 ` [PATCH v2] " Alexey Dobriyan
2008-11-12 0:45 ` David Miller
2008-11-12 6:20 ` [PATCH] nets: Introduce read_pnet() and write_pnet() helpers Eric Dumazet
2008-11-12 6:31 ` [PATCH] net: Cleanup of neighbour code Eric Dumazet
2008-11-12 8:55 ` David Miller
2008-11-12 8:53 ` [PATCH] nets: Introduce read_pnet() and write_pnet() helpers David Miller
2008-11-12 6:21 ` [PATCH] net: ib_net pointer should depends on CONFIG_NET_NS Eric Dumazet
2008-11-12 8:54 ` David Miller
2008-11-12 10:44 ` [PATCH v2] net: #ifdef inet_bind_bucket::ib_net Alexey Dobriyan
2008-11-12 10:50 ` Eric Dumazet [this message]
2008-11-12 12:24 ` [PATCH v3] " Alexey Dobriyan
2008-11-12 12:24 ` David Miller
2008-11-12 10:55 ` [PATCH v2] " Eric Dumazet
2008-11-12 11:16 ` David Miller
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=491AB4F5.2070206@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=adobriyan@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@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;
as well as URLs for NNTP newsgroup(s).