[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45E5933D.4070304@fr.ibm.com>
Date: Wed, 28 Feb 2007 15:35:41 +0100
From: Daniel Lezcano <dlezcano@...ibm.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: netdev@...r.kernel.org, containers@...ts.osdl.org,
openib-general@...nib.org
Subject: Re: [PATCH RFC 18/31] net: Implment network device movement between
namespaces
Eric W. Biederman wrote:
> From: Eric W. Biederman <ebiederm@...ssion.com> - unquoted
>
> This patch introduces NETIF_F_NETNS_LOCAL a flag to indicate
> a network device is local to a single network namespace and
> should never be moved. Useful for pseudo devices that we
> need an instance in each network namespace (like the loopback
> device) and for any device we find that cannot handle multiple
> network namespaces so we may trap them in the initial network
> namespace.
>
> This patch introduces the function dev_change_net_namespace
> a function used to move a network device from one network
> namespace to another. To the network device nothing
> special appears to happen, to the components of the network
> stack it appears as if the network device was unregistered
> in the network namespace it is in, and a new device
> was registered in the network namespace the device
> was moved to.
>
> This patch sets up a namespace device destructor that
> upon the exit of a network namespace moves all of the
> movable network devices to the initial network namespace
> so they are not lost.
>
If you:
* create etun0/etun1
* create a namespace
* move etun1 to this namespace
* rename the etun1 to eth0
* kill the namespace
the former network device etun1 will be lost if you have in your parent
namespace an interface eth0 because it will conflict.
Perhaps, the first name should be restored before moving the device back
to the initial network namespace ?
-- Daniel
ps : nice patchset
-
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