Messages in this thread | | | Date | Sun, 6 Nov 2005 23:42:25 +0800 | From | Bernard Blackham <> | Subject | Re: A possible idea for Linux: Save running programs to disk |
| |
Apologies for the delay.
On Sun, Oct 09, 2005 at 08:13:04PM -0500, serue@us.ibm.com wrote: > Quoting Bernard Blackham (bernard@blackham.com.au): > > 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?
I did try this once by having a 'supervisor' process ptrace every resumed process and translate PIDs inside system calls, but this got very messy very fast - particularly for terminal ioctls. Additionally, it means parents can't get notification of when their children die, and it makes the whole show just that much slower.
Getting them back their original PIDs seems like less effort (so long as they're available). I'm probably shouldn't admit to what I'm currently doing - editing last_pid through /dev/kmem, to force the next pid fork() returns. (Unbelievably racy, but works as a temporary measure).
Bernard.
- 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/
| |