Re: Task destruction

[Niels Möller]

Marcus Brinkmann <address@hidden> writes:

> On Tue, Aug 06, 2002 at 04:13:18PM +0200, Niels Möller wrote:
> > But then the proc server in the child hurd can neither track nor
> > control its proceses,
> 
> Uh, of course it can, as usually tasks register themselves with the proc
> server voluntarily.

Sure, but the problem is tasks that don't register themselves. I still
want the Right Thing to happen for users, processes and un-registered
tasks inside a child hurd.

> I think you are missing one very important paradigm here, and that is
> simplicity.  You forget that this task server we are talking about _must_ be
> used by all personalities running on the L4 system.  It is something you can
> not avoid.  So its operation should be simple, and lean, and it should not
> itself invent any policy except that much of policy as belongs into
> it.

I think the complexity of the scheme I proposed is smaller than you
think. In any case, we must have some an inherited magic token (to let
at least the system proc server keep track of who owns a non-process
task). And we must have a list of handles, in order to support
reliable no-senders notifications (anyone giving a handle to the task
needs ask the task-server to receive a death notification, as I
understand the current libport scheme).

So what I propose to add on top of this is: 1. Make the inherited
token a handle. 2. Put all handles in the same list, using one or two
flags to distinguish between inherited control handles and others. 3.
Introduce some reasonably simple and very general rules for how the
control-type handles can be modified:

  Anyone can adopt an orphaned task.

  Anyone can be a controller for tasks it creates.

  One can only modify handles that refer to oneself.

> The second thing you are probably missing is that the same task server must
> be used by non-POSIXish, or even non-Hurdish systems and
> personalities.

I'm aware of that. I think I'm willing to assume that all
personalities using shared servers like the task server use the same
libport conventions, though, for things like transfer of port
rights/handles.

> All the other features, like deciding who can kill tasks, can be in
> the proc server, where they are now, or even in proxy task servers.

The way I divide that decision making is as follows: The task server
knows who controls each task, in the form of a handle <master, id>. The
task server lets the master do whatever it wants to the task, and
treats the id as an opaque magic value.

The usual case is that the master is a proc server. In this case, the
id is the pid of the responsible process (often the process itself),
and this provides the information proc needs (uid, login group, etc)
to decide when to use its power over the task.

There are plenty of variations on the theme, but I think this
organization is quite natural. And the task server is both reasonably
simple and quite general, which means that the variations I
can think of can be implemented in proc, with exactly the same
task-server.

There are other issues that I'm afraid will also add complexity to the
task server (singlestepping a task under debugger control, resource
information and limits, etc), but this message is too long already.

/Niels