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

[serue@us.ibm.com]

Quoting Bernard Blackham (bernard@blackham.com.au):
> 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?

-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/