Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Dave Hansen <haveblue@us.ibm.com>]

On Tue, 2005-11-15 at 01:06 -0800, Paul Jackson wrote:
> No - tasks get the pid the kernel gives them at fork, as always.
> The task keeps that exact same pid, across all checkpoints, restarts
> and migrations.  Nothing that the application process has to worry
> about, either inside the kernel code or in userspace, beyond the fork
> code honoring the assigned pid range when allocating a new pid.

The main issues I worry about with such a static allocation scheme are
getting the allocation patterns right, without causing new restrictions
on the containers.  This kind of scheme is completely thrown out the
window if someone wanted to start a process on their disconnected laptop
and later migrate it to another machine when they connect back up to the
network.  

> The real complexity comes, I claim, from changing the pid from a
> system-wide name space to a partially per-job namespace.  You can
> never do that conversion entirely and will always have confusions
> around the edges, as pids relative to one virtual server are used,
> incorrectly, in the environment of another virtual server or system
> wide.

You're basically concerned about pids "leaking" across containers, and
confusing applications in the process?  That's a pretty valid concern.
However, the long-term goal here is to virtualize more than pids.  As
you noted, this will include thing like shm ids.  Yes, I worry that
we'll end up modifying a _ton_ of stuff in the process of doing this.

As for passing confusing pids from different namespaces in the
filesystem, like in /var/run, there are solutions in the pipeline.
Private namespaces and versioned filesystems should be able to cope with
this kind of isolation very nicely.

-- Dave