[Devel] Re: [PATCH 0/6] netns: add linux-vrf features via network namespaces

Daniel Lezcano dlezcano at fr.ibm.com
Fri Oct 31 13:48:25 PDT 2008


Eric W. Biederman wrote:
> Thinking it over a little more I have the following thought.
> 
> For binding a socket to a namespace let's use the a fd arg.
> That way we can either supply another existing network socket
> or the result of an open call.  Simple, and faster if you
> are creating more than one socket in the other network namespace.
> 
> I really don't like the idea of binding a socket into a namespace.
> Especially after looking at the arguments to socket(2).
> The network namespace may be incomplete and you may create a socket
> in a network namespace that way that we could not exist normally.
> That plus it puts lots of races in code that finds the namespace of
> a socket.
> 
> 
> So in some form let's implement socketat. 
> int socketat(int ns, int domain, int type, int protocol, int flags);

Is the 'ns' arg a fd from a socket just after the unshare ?

> We need the flags field so we can accomodate the O_CLOEXEC flag.
> 
> 
> That should be very straight forward.  Implementable now, without
> a magic filesystem.   And then the filesystem would just provide
> the global naming and process independence.

Assuming the ns arg is a fd from a socket created in a specific network 
namespace, I agree this is quite easy to implement and consistent with 
the refcounting of the netns. Furthermore that follows the logic of the 
network devices, one can be created in another netns using the pid as 
identifier.
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list