Matt Helsley <matthltc@xxxxxxxxxx> writes: > On Tue, Feb 23, 2010 at 12:00:55PM -0800, Eric W. Biederman wrote: >> jamal <hadi@xxxxxxxxxx> writes: >> >> > Added Daniel to the discussion.. >> > >> > On Tue, 2010-02-23 at 06:07 -0800, Eric W. Biederman wrote: >> >> jamal <hadi@xxxxxxxxxx> writes: >> > >> >> > Does the point after sys_setns(fd) allow me to do io inside >> >> > ns <name>? Can i do open() and get a fd from ns <name>? >> >> >> >> Yes. My intention is that current->nsproxy->net_ns be changed. >> >> We can already change it in unshare so this is feasible. >> > >> > I like it if it makes it as easy as it sounds;-> With lxc, >> > i essentially have to create a proxy process inside the >> > namespace that i use unix domain to open fds inside the ns. >> > Do i still need that? >> >> That point of the mount to hold a persistent reference to the >> namespace without using a process. > > I think technicaly it's still held using processes, only now it's > much more indirect: > > netns <- mount <- mount namespace(s) <- process(es) True. The practical difference is that it doesn't require a dedicated process which is a big improvement operationally. > Using a mount requires keeping names for the namespaces themselves > in the kernel which is a problem we've largely avoided so far. > The nscgroup is an example of the messes that creates, I think. And it > further complicates c/r -- we'd need to checkpoint and recreate the > names of the namespaces too. So we'll need a namespace for the names of > the namespaces to make restart reliable won't we? Makes my head spin... This is strictly different. It may require a bit of extra support from checkpoint/restart because it introduces some more user visible objects but the names themselves are nothing special. The name that userspace sees and deals with is the name of the mount point. No new namespaces are required. Eric -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
