[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150310.132901.107747405992138134.davem@davemloft.net>
Date: Tue, 10 Mar 2015 13:29:01 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: ebiederm@...ssion.com
Cc: ja@....bg, edumazet@...gle.com, netdev@...r.kernel.org,
stephen@...workplumber.org, nicolas.dichtel@...nd.com,
roopa@...ulusnetworks.com, hannes@...essinduktion.org,
ddutt@...ulusnetworks.com, vipin@...ulusnetworks.com,
shmulik.ladkani@...il.com, dsahern@...il.com
Subject: Re: [PATCH net-next 3/6] tcp_metrics: Add a field tcpm_net and
verify it matches on lookup
From: ebiederm@...ssion.com (Eric W. Biederman)
Date: Tue, 10 Mar 2015 12:06:32 -0500
> David Miller <davem@...emloft.net> writes:
>
>> From: ebiederm@...ssion.com (Eric W. Biederman)
>> Date: Tue, 10 Mar 2015 01:59:48 -0500
>>
>>> If we actually really care about struct net going away it would be
>>> much better to globally replace struct net with a typedef that looks
>>> something like:
>>>
>>> #ifdef CONFIG_NET_NS
>>> struct net_ref {
>>> struct net *net;
>>> };
>>> #else
>>> struct net_ref {
>>> };
>>> #endif
>>> typedef struct net_ref net_t;
>>>
>>> That would remove the need for write_pnet and read_pnet, make it
>>> impossible to forget net_eq and make network namespace arguments to
>>> functions also boil away at compile time if the network namespace code
>>> was not enabled.
>>>
>>> That was the original design and I forget why we didn't do that with
>>> struct net. But we did not.
>>
>> This keeps the ifdefs out of foo.c code, so I like it.
>
> Alright. It does wind up requiring things like:
Another approach is to use a macro for the instantiation of a "struct
net *" member.
It could evaluate to "struct { } x;" when NETNS is disabled.
Then you don't need all the special accessors, read_pnet() and
write_pnet() are sufficient.
--
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