[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