[ucc] process trees/groups issue

Andrew Bailey acolyte at ucc.gu.uwa.edu.au
Mon Nov 7 09:41:04 WST 2005


On Mon, Nov 07, 2005 at 09:28:41AM +0800, Bernard Blackham wrote:
> 
> Not that easy unfortunately.
> 
> The bigger picture is particularly evil. It's for CryoPID to be able
> to restore a frozen process and give it the right process ID. 
>You
> have an executable file which contains the frozen process.  The user
> executes it from the shell (task1), and that is assigned the next
> available pid. In order to get the process ID desired, task1 fiddles
> with /dev/kmem and then fork()s off another process (task2) with the
> right pid, and this turns into the resumed process.
> 
> I want all of this to be transparent to the user.
>

Err then write a version of exec to assign the pid and chuck it all in a
kernel module. 

If you want to restore a frozen process and mess with process id's ( and
hack kmem ) then it all  sounds like kernel mode stuff to me. 

Trying to do that in user mode is fraught with peril :)  

Andrew.

> Currently task1 just hangs around wait()ing for task2, but it serves
> no other purpose and I thought it'd be good if it could just
> disappear. I've nearly resigned to the fact that it can't though,
> without further soiling /dev/kmem.
> 
> I've got somebody else looking at a setpid() system call which I
> might try and get merged into the kernel - that'll resolve the issue
> entirely =)
> 
> Regards,
> 
> Bernard.
> 
> -- 
>  Bernard Blackham <bernard at blackham dot com dot au>

-- 
"The hot dog eating contest is not only a beautiful display of athleticism,
it is a fundamental way for citizens of all nations to display patriotism," 
- Wayne Norbitz 


More information about the ucc mailing list