[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ba6a1b18-959e-e307-45fa-e0da9d6f0b0f@6wind.com>
Date: Thu, 30 Aug 2018 17:49:12 +0200
From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
To: Christian Brauner <christian.brauner@...onical.com>,
Kirill Tkhai <ktkhai@...tuozzo.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
davem@...emloft.net, kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
pombredanne@...b.com, kstewart@...uxfoundation.org,
gregkh@...uxfoundation.org, dsahern@...il.com, fw@...len.de,
lucien.xin@...il.com, jakub.kicinski@...ronome.com,
jbenc@...hat.com
Subject: Re: [PATCH net-next 0/5] rtnetlink: add IFA_IF_NETNSID for
RTM_GETADDR
Le 30/08/2018 à 16:45, Christian Brauner a écrit :
[snip]
> Introducing the IFA_IF_NETNSID property will not make the netlink
> interface less modular. It is a clean, RTM_*ADDR-request specific
> property using network namespace identifiers which we discussed in prior
> patches are the way to go forward.
>
> You can already get interfaces via GETLINK from another network
> namespaces than the one you reside in (Which we enabled just a few
> months back.) but you can't do the same for GETADDR. Those two are
> almost always used together. When you want to get the links you usually
> also want to get the addresses associated with it right after.
> In a prior discussion we agreed that network namespace identifiers are
> the way to go forward but that any other propery, i.e. PIDs and fds
> should never be ported into other parts of the codebase and that is
> indeed something I agree with.
Yes, I agree with this and I think this series go to the right direction.
Maybe I would choose a more generic name for the attribute, something that can
be used in other netlink families (xfrm, netfilter, ...) also.
What about IFA_TARGET_NSID?
Powered by blists - more mailing lists