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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.