Date: Mon, 14 Nov 2005 17:51:40 -0800
From: Paul Jackson <pj@sgi.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: linux-kernel@vger.kernel.org, frankeh@watson.ibm.com, haveblue@us.ibm.com
Subject: Re: [RFC] [PATCH 00/13] Introduce task_pid api
Message-Id: <20051114175140.06c5493a.pj@sgi.com>
In-Reply-To: <20051115010155.GA3792@IBM-BWN8ZTBWAO1>
References: <20051114212341.724084000@sergelap>
	<20051114153649.75e265e7.pj@sgi.com>
	<20051115010155.GA3792@IBM-BWN8ZTBWAO1>
Organization: SGI
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1341
Lines: 32

Serge wrote:
> But when one of the
> processes looks for process 10, task_vpid_to_pid(current, 10) will return
> the real pid for the vpid 10 in current's pidspace.

So a "kill -1 10" will mean different things, depending on the pidspace
that the kill is running in.  And pid's passed about between user
tasks as if they were usable system-wide are now aliased by their
invisible pidspace.

Yuck.  Such virtualizations usually have a much harder time addressing
the last 10% of situations than they did the easy 90%.

How about instead having a way to put the pid's of checkpointed tasks
in deep freeze, saving them for reuse when the task restarts?

System calls that operate on pid values could error out with some
new errno, -EFROZEN or some such.

This would seem far less invasive.  Not just less invasive of the code,
but more importantly, not introducing some never entirely realizable
semantic change to the scope of pids.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/