Messages in this thread | | | Date | Sun, 9 Oct 2005 20:13:04 -0500 | From | serue@us ... | Subject | Re: A possible idea for Linux: Save running programs to disk |
| |
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/
| |