Re: (pspace,pid) vs true pid virtualization

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

Quoting Hubertus Franke (frankeh@watson.ibm.com):
> >>- Should a process have some sort of global (on the machine identifier)?
> 
> First establish whether that global ID has to be persistent ...
> I don't see why ! In which case the TASK_REF is the perfect global ID.

The task_refs were only intended to be used in the kernel, iiuc.

...

> >>- Should we be able to have processes enter a pid space?
> >
> >
> >IMO that is crucial.
> 
> Existing ones .. now that is potentially difficult to do. Particular
> if you want to enter a pidspace that has already been migrated.
> Because ones assigned pid might already been taken in the target pspace.

Well the answer changes depending on whether the question asks
about pid spaces, or full containers.  For full containers, you have
problems with unsharing various pieces of namespace.  But for the
pidspace, a simple function with clone() semantics makes perfect sense.
So your code does:

	child_pid = pidspace_clone(pspace_id);
	if (child_pid == 0) {
		/* we are inside pspace 'pspace_id' with a random
		   pid which is unique in that pspace */
	} else {
		/* the child_pid is known by some other pid in it's
		   own pspace, but in our pspace it's known and hashed
		   by 'child_pid'.  child_pid and that other pid are
		   likely different.
		 */
	 }

So long as we're just talking about the pidspaces, I don't see any
unexpected side effects here.

-serge