Volkmar Uhlig <[EMAIL PROTECTED]> 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. Regards, /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd