l4-hurd
[Top][All Lists]
Advanced

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

proc overhaul


From: Marcus Brinkmann
Subject: proc overhaul
Date: Sun, 25 May 2003 23:07:07 +0200
User-agent: Mutt/1.5.3i

Hi,

this is not yet a finished suggestion how proc should look like, but more
a plan how it can be redesigned to meet the requirements in the L4 based
Hurd system.

Currently, proc has several functions:

* Gather host data, like uname, and things like that.
  This will be in its own interface, but it can stay in the proc server.
  Programs could get a separate handle to a HOST server in the initial
  handle array, but not sure if that has really any advantage.

* Provide the msgport to other tasks, so they can send signals and stuff.

* Implement process semantics, like waiting for childs to finish and sending
  SIGCHILD.

* Provide further data about processes (for core dump, resource usage etc)

I am happy with the host interface (except for some small changes).

The msgport can not be provided by proc anymore.  This is because a server
can not return handles to other tasks that it doesn't trust to users.  So,
programs should look up the task ID handle from the PID, and then contact
the task.  The task can return an empty handle after creating their own
task ID handle to the user's task.  Then the user has to follow up with a
reauthentication.  This moves the critical part of the process to process
comunication outside of proc.  This will work just fine.

However, the msgport is also used by proc itself to send signals like
SIGCHILD.  This is not nice, and should be replaced by notification
messages.  So, an event that would trigger a SIGCHILD is reported in a
notification message.  Notifications have still to be worked out, but they
are the generic mechanism to report events from server to user.
We can not rely on direct messages from process to process because a
SIGCHILD has also to be reported in case of a SIGKILL of the child (which
doesn't require cooperation by the child task).

That leaves proc_wait and friends.  That should be implemented in the user
(ie in glibc), too.  The necessary information should also be received by
notifications from proc.

So, proc needs a major overhaul to make it robust.  Notifications will be
essential for most features.  Authentication of signals that are not emitted
or enforced by proc will be directly between sender and target.

Thanks,
Marcus



-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/




reply via email to

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