(pspace,pid) vs true pid virtualization

["Serge E. Hallyn" <serue@us.ibm.com>]

Hi,

the lkml discussion on pid virtualization has been covering many of the
issues both relating directly to pid virtualization, and relating to
optimizations in the two specific implementations.

However, if we're going to get anywhere, the first decision which we
need to make is whether to go with a (container,pid), (pspace,pid) or
equivalent pair like approach, or a virtualized pid approach.  Linus had
previously said that he prefers the former.  Since there has been much
discussion since then, I thought I'd try to recap the pros and cons of
each approach, with the hope that the head Penguins will chime in one
more time, after which we can hopefully focus our efforts.

Issues with the (pspace,pid) pair like approach:
	1. how do we reap zombies when the "real" init process
		is not visible from within a container?
	2. global process view
		userspace tools may need to be taught about containers
		in order to provide any container with a "global pid view".
		i.e. all tasks could be listed as (pspace,pid), or as
		pid1/pid2/pid3 where pid1 is creator of pid2's pspace
		which is creator of pid3's pspace...
	3. no half-isolation mode?
		containers are always fully isolated.  This doesn't
		need to be the case if userspace tools are taught
		to deal with containerids.  On the other hand, it
		can also be considered one of it's strenghts.

Issues with pid virtualization;
	1. maintenance/correctness
		pids and vpids are now different and must not be mixed.
		Enforcing this simply in the kernel is a concern.  Sparse
		may be useful here, or simply using different opaque types.
	2. slowdown after migration
		before checkpt, pid==vpid.  After restore or migration,
		vpid = hash(pid) or vice versa.

Please add any issues I've not listed, or correct anything you feel I've
misrepresented.

thanks,
-serge