Re: Task destruction

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> However, there are now two cases:  The second Hurd system was booted by a
> regular user.  [...]  You can consider this Hurd system to be
> in a child position wrt to the first Hurd system if you want.

Right, I was thinking about this case.

> But if that second Hurd system runs privileged, it is in the same
> position as the first Hurd system. [...] In any case, those two Hurd
> systems should be symmetrical, and in a neighour position.

Right. That's even more true if all coordination of hardware access is
done via "non-hurd" servers, without one of the hurds acting as a
proxy for the other. The task server and the memory server can be
viewed as two such servers. When it comes to access to other hardware
(e.g. disks, or indivudual partitions on a disk), I've not seen any
solution yet, but I'm sure something could be done if we want to push
the neighbour model even further.

> 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.

Exactly what attributes do the unregistered tasks get, besides the
pid? In particular, who is allowed to kill them, or control them in a
debugger? To me it seems that if we want the "every task is a process"
model, we at least have to associate some uid to the task. And it gets
even more complicated if you take login groups into account (where uid
is not enough). The "responsible process" model seems a little more
robust to me, but I should perhaps not argue strongly for it at this
point. Perhaps we should call it "parental guidance"? ;-)

/Niels