Re: [PATCH 1/1] cr: define CHECKPOINT_SUBTREE flag and sysctl

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting Alexey Dobriyan (adobriyan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):
> On Mon, Apr 27, 2009 at 01:07:17PM -0500, Serge E. Hallyn wrote:
> > Heh, because there is no such thing as a 'container'.
> 
> Oh, yes, there is.
> 
> Set of tasks shares set of uts_ns, ipc_ns, mnt_ns, pid_ns and net_ns.
> No other task shares this set.
> Pid_ns set has tree hierarchy.
> All user_ns which come from credentials of set of tasks aren't shared
> with other tasks.
> 
> Such set of tasks logically forms a container.

Sure, that definition makes sense, but so do the other existing
uses of the term.  You can hijack already-overloaded terms if you want,
but it's not wise, and will hamper communications when everyone reads
something different into your message.

You don't mention the freezer control group (or any of the others).
Your patchset has the kernel freeze the tasks for the duration of the
checkpoint, but that's one aspect of your patchset which, while
convenient, is imo hard to really justify not doing in user-space.

> > There is a set of tasks in the same freezer control group, and it's
> > possible that there is a task not in that cgroup which is in the same
> > utsname as the rest of the tasks in that freezer cgroup.