Re: A possible idea for Linux: Save running programs to disk

From: serue
Date: Sun Oct 09 2005 - 20:13:34 EST

Quoting Bernard Blackham (bernard@xxxxxxxxxxxxxxx):
> On Sun, Oct 02, 2005 at 08:57:26AM -0400, Ed Tomlinson wrote:
> > Is there any kernel api that adding would make cryopid more
> > dependable/cleaner?
> Currently a fair bit of information is obtained by injecting code
> into the process's memory space, executing it, and reaping out the
> results (eg, termcaps, file offsets, fcntl states, locks, signal
> actions, etc). Can't think of ways to make it cleaner off the top
> of my head, but I'm open to ideas.
> Seeing as you asked though, here's my wishlist :) I don't expect all
> of these to be implemented, but every bit would help. Issues I
> haven't been able to address so far:
> - Processes that cache their PID and need it, or rely on PIDs of
> their children.
> Some way to request a given PID when cloning/forking (or on the
> fly even) would make life easier.

Have you considered any ways of implementing this? Perhaps the simplest
way would actually be to allow a process set to be started in some kind
of job/jail/container/vserver, where any userspace query of or by pid
uses the virtual pid - which might collide with a virtual pid in some
other container - but of course the kernel continues to track by real
pids. So pid 3728 may be vpid 2287 in job 3. A process inside job 3
just asks to kill -9 2287, whereas a process not in a job must ask to
kill pid 3728, and a process in job 2 can't touch tasks in job 3. Is
there another way this could work?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at