Re: Task destruction

[Marcus Brinkmann]

On Mon, Aug 05, 2002 at 11:23:34PM +0200, Niels M?ller wrote:
> >From this example, I also think it is clear that the relationship
> between the two hurds is assymetric, and I think the
> parent-hurd/child-hurd terminology makes more sense than
> "neighbour-hurd".

I don't have time to consider everything you wrote so far in this thread,
but I think you are heading into a direction that is more complicated than
necessary.

If a Hurd system is booted the first time, obviously nothing keeps track
of its processes than itself.  If you boot a second Hurd system, then
there will still only be one task server, which is L4-ish, and not Hurd-ish.
This task server will keep track of the dependency between the boot program
in the one Hurd system and the processes in the other Hurd system.

However, there are now two cases:  The second Hurd system was booted by a
regular user.  Than this implies that the whole second Hurd system runs
unprivileged if you look at the system as a whole, eg it runs with
the permission of a normal user (this user might have access to some hard-
ware components, but in general the user is not root).  In particular,
the second Hurd system will usually not get control over all the other
processes and tasks in the system.  You can consider this Hurd system to be
in a child position wrt to the first Hurd system if you want.

But if that second Hurd system runs privileged, it is in the same position
as the first Hurd system.  In fact, the task server should not be able to
distinguish both.  The second Hurd system should be able to control the
processes in the first Hurd system.  This will make it possible to replace
the whole system by another instance (maybe with a way to move state from
one to another).  In any case, those two Hurd systems should be symmetrical,
and in a neighour position.  Now, you might point out that the task server
knows about the boot process <-> second Hurd system processes relationship.
So what?  It's just a data field in the task server that groups processes
together.  It's an extra piece of information, that is of little value to
the second Hurd system, but helpful for the first.

If you look at the current implementation of proc, a proc running with
privileges will always display _all_ tasks in the system and assign a pid to
them.  This pid is unique to this proc server.  Unregistered tasks will
just get a pid, so you can kill them.  So if you boot a Hurd system as root
user, you can either kill the second system from the first, or the first
from the second, it doesn't matter.  If you boot a Hurd system as normal
user, the proc server can not get a list of all tasks in the system (it
is a privileged call in Mach), so you only get PIDs for your local processes.
I think this is how it should be.

The reason to have a parent<->child relationship between tasks is to make it
possible to see which tasks belong together, so that if two users run
sub hurds (sub because the users are unprivileged), the root user can easily
kill one of the sub hurds without confusing it with the other at the process
level.

Thanks,
Marcus

Thanks,
Marcus