Hello all, I'd like to propose a new system call, I know I'll probably be flamed, but here goes. Today there is no way to get a process which has been orphaned, and thus become a child of init, back as a child of another process. This is annoying me, please allow me to explain why. The CONFIG_CHECKPOINT_RESTORE feature enables a useful little thing in proc which I've been taking advantage of to make some interesting omnipresent desktop monitoring features built into my own composited window manager. That thing is the /proc/$pid/task/$pid/children file. Using this file, I've created scoped per-window process monitors which can efficiently limit their monitoring to only the client pid of the X window and its decendants. These monitors are always running, but visibility is toggled when desired by a keypress, efficiency is important and the children file helps tremendously in this regard. So I'm thrilled with all this and everything is fantastically efficient and simple, until the first time I detach from my screen session and reattach. Initially, I'll have a scenario like: xterm bash screen -S stuff screen -S stuff bash bash top bash vi foo.c bash make sh -c cc -Wall ... cc1 -quiet -I ... bash Behind these rows of text I have user/cpu graphs for each process sliding by. After detaching from screen, then reattaching, this is what the above turns into, as you can probably predict: xterm bash screen -dr stuff All subsequent processes created through my interactions with this screen are lost to the monitoring, since the "screen -S stuff" backend is now stuck being a child of init. With the attached adopt() syscall patch, and a 1 line change to screen's attacher function invoking adopt(), I get the following on reattach: xterm bash screen -dr stuff screen -S stuff bash bash top bash vi foo.c bash make sh -c cc -Wall ... cc1 -quiet -I ... Which makes me very happy, dance around the room happy, and I'm not a dancer. Here is a screenshot of the results enabled by the patch: http://pengaru.com/~swivel/vwm/screen_sys_adopt.png Thanks for reading, and hopefuly considering this addition, I'm sure there are other uses as well. Please CC me in any replies as I'm not currently subscribed. Regards, Vito Caputo