[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emulating no-senders notifications in L4?

From: Niels Möller
Subject: Re: emulating no-senders notifications in L4?
Date: 16 Nov 2001 15:54:28 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Volkmar Uhlig <volkmar@ira.uka.de> writes:

> The general idea in L4 is to have a server which creates and deletes
> tasks. This server "owns" the tasks and is the only one allowed to
> execute the task_new syscall for them. L4 tries to keep task allocation
> policy out of the kernel allowing user apps to replace the task server.
> If an application wants to create or delete a task you simply send an
> RPC. For L4-HURD I could imagine to have the server sending death-name
> notifications.

Does L4 notify this special tasks-server when tasks die? Or what
happens if a task dies violently? Do even suicidal tasks have to talk
to the special task-server to be able to kill themselves?

To me, it seems that for resource cleanup to happen automatically and
reliably, all resources must to be registered with the task-server,
and there must be no way to unregister a resource without also
destroying it or giving up access to it. To me, this seems to imply
that all access to the resources must be indirect.

A portright (for instance) is an opaque id, much like an fd on unix.
The only thing a task can do with it is to communicate with the
task-server, asking it to do stuff with it. The task server would
check that the id is valid, and then forward the request to the real
server responsible for the resource. Other servers will only accept
requests sent via the task-server.

This sounds a lot like having a mach-port-server that handles all ipc.
Is that the way to go? How efficiently can the extra redirection be
handled in L4?

If we go in this direction, there's no real use of any L4-security;
the only mechanism that would be obviously useful is a flag "accept
rpc only from this specific task", that every task but the
task-server/mach-port-server could use.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]