Messages in this thread | | | Date | Wed, 9 Nov 2005 13:15:54 +1100 | From | Peter Chubb <> | Subject | Re: A possible idea for Linux: Save running programs to disk |
| |
>>>>> "Bernard" == Bernard Blackham <bernard@blackham.com.au> writes:
Bernard> Apologies for the delay. On Sun, Oct 09, 2005 at 08:13:04PM Bernard> -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?
Bernard> I did try this once by having a 'supervisor' process ptrace Bernard> every resumed process and translate PIDs inside system calls, Bernard> but this got very messy very fast - particularly for terminal Bernard> ioctls. Additionally, it means parents can't get Bernard> notification of when their children die, and it makes the Bernard> whole show just that much slower.
Indeed.
For HibernatorII (the checkpoint/restart system developed for UXP/M and Irix) we introduced a new, privileged, system call : pid_clone() that took the same args as clone() but an extra PID argument. If the process id was available, it'd use it, otherwise it would fail.
-- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au The technical we do immediately, the political takes *forever* - 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/
| |