Messages in this thread | | | Date | Mon, 14 Nov 2005 20:29:31 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC] [PATCH 00/13] Introduce task_pid api |
| |
Quoting Paul Jackson (pj@sgi.com): > 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%.
For simplicity, the only pids a process will see are those in its own pidspace, and the only controls (I expect) will be the ability to start a new pidspace, and request a pid. So it is no more complicated than the vserver model, where a process becomes pid 1 only for other proceses in the same vserver, and process don't see processes in other vservers - except that now every process in the pidspace can be known as a different pid, not just the first.
> 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.
Unfortunately that would not work for checkpoints across boots, or, more importantly, for process (set) migration.
> 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.
Hopefully the next patchset, implementing the pid-vpid split, will show it's not as complicated as I've made it sound.
Of course, if it remains too complicated a conceptual change to be mergeable, we're better off knowing that now...
thanks, -serge - 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/
| |