Re: RFC: Multiple instances of kernel namespaces.

[Hubertus Franke]

Serge E. Hallyn wrote:
> Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx):
>
> > At this point I have to confess I have been working on something
> > similar, to IBM's pid virtualization work.  But I have what is at
> > least for me a unifying concept, that makes things easier to think
> > about.
> >
> > The idea is to think about things in terms of namespaces.  Currently
> > in the kernel we have the fs/mount namespace already implemented.
> >
> > Partly this helps on what the interface for creating a new namespace
> > instance should be.  'clone(CLONE_NEW<NAMESPACE_TYPE>)', and how
> > it should be managed from the kernel data structures.
> >
> > Partly thinking of things as namespaces helps me scope the problem.
> >
> > Does this sound like a sane approach?
>
>
> And a bonus of this is that for security and vserver-type applications,
> the CLONE_NEWPID and CLONE_NEWFS will often happen at the same time.
>
> How do you (or do you?) address naming namespaces?  This would be
> necessary for transitioning into an existing namespace, performing
> actions on existing namespaces (i.e. checkpoint, migrate to another
> machine, enter the namespace and kill pid 521), and would just be
> useful for accounting purposes, i.e. how else do you have a
> "ps --all-namespaces" specify a process' namespace?
>
> Doubt we want to add an argument to clone(), so do we just add a new
> proc, sysfs, or syscall for setting a pid-namespace name?
>
> Do we need a new syscall for transitioning into an existing namespace?
>
> thanks,
> -serge


Just addressed a few of this in my previous reply to the other thread.

However, question here is whether the container (as we used it) provides
the "binding" object for these clones. One question for me then is
whether cloning of namespaces is always done in tandem.
As you are bringing the migration up, we can only clone fully contained
namespaces ! One could make that a condition of the migration or build
it right into the initial structure. Any thoughts on that ?

-- Hubertus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/