Le 02/07/2014 22:09, Eric W. Biederman a écrit :

Nicolas Dichtel [off-list ref] writes:

quoted

The goal of this serie is to be able to multicast netlink messages with an
attribute that identify a peer netns.
This is needed by the userland to interpret some informations contained in
netlink messages (like IFLA_LINK value, but also some other attributes in case
of x-netns netdevice (see also
http://thread.gmane.org/gmane.linux.network/315933/focus=316064)).

Each network namespaces allocates its own ids for other netns (including
itself). The user can retrieve these ids via a new netlink messages, but only
if he has a FD which points to this netns. Dump is not implemented so that a
user cannot get the whole netns list.

The goal of this RFC is mainly to validate the principle, ie patch 1/5 and 2/5.
Patch 3/5 and 4/5 shows an example of how to use these ids in rtnetlink
messages. And patch 5/5 shows that the netlink messages can be symetric between
a GET and a SET.

This approach fundamentally breaks process migration, and calls for a
namespace of namespaces.

Maybe there is no other solution. Network people uses netns to implement
"virtual router", ie only network namespaces are used. Userland daemons
manage a set of netns. These daemons need to be able to identify a peer netns
when netlink messages from kernel are parsed. For now, these netlink messages
are incomplete and contain information that cannot be interpreted (like the
IFLA_LINK ifindex).

Can you give me more details about the "process migration"? How does it work
when you have a veth tunnel between two netns?

Which means this is a major mess that really isn't going to work because
it generates more problems than it solves.

It's just a netns inside another netns, or to be easier to figure out, one or
more virtual router inside a netns ;-)

Regards,
Nicolas