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 <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
