![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-11-15 03:32 [from the cache] ©2003-2008 | |||||||||||||