On Jan 17, 2006, at 11:19, Suleiman Souhlal wrote:
Why does there need a separate pid space for each container? You
don't really need one to make sure that only processes in the same
containers can see each other.
On Jan 17, 2006, at 11:03, Alan Cox wrote:
This is an obscure, weird piece of functionality for some special
case usages most of which are going to be eliminated by Xen. I
don't see the kernel side justification for it at all.
Maybe you should remap it the other side of the user->kernel
boundary ?
To answer both questions at the same time, this is to make it
practical to reliably freeze and restore whole process-trees/jobs,
possibly restarting or migrating to a different computer in-between.
Such freeze/restore code is mostly possible now, except for programs
that store a pid internally to send a signal to another process. The
usage would be something like this:
start:
create container:
run jobs
freeze
for each process/thread in the container:
send SIGSTOP to halt execution
for each process in the container:
store process data, filehandles, vpid, etc
restore:
create container:
iterate over the frozen processes in the freeze file:
clone_with_pid(flags, original_vpid);
adjust session, connect filehandles, etc
remap shared memory, etc
block on atomic "resume" variable in mmap-ed file
set "resume" to 1
The end result is that you could freeze and resume _any_ process tree
in a container, even ones that do weird things with filehandles,
sockets, pids, etc. Personally I would find this useful to migrate
an extensive memory-leak-debugging session in a large application
over from laptop to desktop or vice versa. You could also freeze/
migrate/restore a whole X session (not including the X process
itself, but all the client apps). You could not do this at all for
statically-linked applications without kernel support, and it would
be rather inefficient to do even for dynamically-linked ones.
The one other option would be to allow opening a file /proc/$PID/
control, to which you could write a signal number, and require
freezable programs to use that interface to reliably send signals
(This also makes signals non-racy if you're reusing all 60000+ pids
on a regular basis). This has the disadvantage of not even working
for existing dynamically-linked programs either..
Cheers,
Kyle Moffett
--
There is no way to make Linux robust with unreliable memory
subsystems, sorry. It would be like trying to make a human more
robust with an unreliable O2 supply. Memory just has to work.
-- Andi Kleen
-
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]
