[Top][All Lists]

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

Re: Task startup

From: Niels Möller
Subject: Re: Task startup
Date: 22 Jan 2004 18:08:44 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Johan Rydberg <address@hidden> writes:

> That is true, with the exception of a few special capabilities that is
> used by the "startup glue code."   The glue code will only operate on
> "raw" capabilities (server thread, cap id) since it is not linked against
> libhurd-cap.   The startup code must be able to identify these caps.
> That could ether be done by separate them from the othere caps, or list
> the caps in a special order (say; primary container, task cap, others..)

Special order is what the current Hurd does (for Mach ports). A simple
alternative is a list with tags that say what each entry on the list

But I think the number of capabilities that need to be listed in the
startup page is *very* limited: There should be a reference to a
parent task. The new task will have to talk to its parent to get
copies of all other capabilities it needs or should inherit, using the
handle transfer protocol. (For wortel modules, the wortel capability
may be a special case).

Here, "parent" means a task that owns a control handle to the new
task, and which creates its first thread. It's usually the same task
which created the new task, but not always (in the setuid case, it's
the filesystem).

At least, that seems to be the simplest way to do it. Otherwise, if
the new task should be given capabilities before the first thread is
started, then we need a variant of the handle transfer protocol that
lets the parent give away arbitrary capabilities to a task it
controls, without cooperation from the receiving task (which hasn't
got any thread running yet). I think that's possible, but I don't
think it is necessary, and the handle transfer protocol seems complex
enough without it.

With the expectation that the startup code will contact the parent
task to get additional information and capabilities, it's not
necessary to but the command line arguments in the initial startup
page, but it seems like a convenient thing to do. Simply because we'll
anyway need *some* ipc with a grant item or string item to pass it


reply via email to

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