[Top][All Lists]

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

Re: physmem, simple containers

From: Marcus Brinkmann
Subject: Re: physmem, simple containers
Date: Tue, 27 Jan 2004 15:29:15 +0100
User-agent: Mutt/1.5.4i

On Tue, Jan 27, 2004 at 02:14:02PM +0100, Niels Möller wrote:
> Should it be a plain reference, or a control handle? It's not at all
> obvious to me why wortel should need any task handles at all, and in
> particular not control handles. This is under the assumption that it's
> physmem, not wortel, that is responsible for starting the bootstrap
> tasks.

This assumption is wrong.
> On the other hand, the task server will need a capability that lets it
> talk to wortel.

Wortel does not understand capabilities.  The cap system is too heavy for
wortel.  Instead, wortel keeps track of a small list of tasks which are
allowed to talk to wortel.  A "wortel cap" is just an index into this list.
I am not sure we need to be able to "pass on" "wortel caps", but if we need
to, it will be a simple extension of the list.  It can be made a little bit
more fancy than that, but it's a far cry from the cap system.

> (I'm tempted to not treat wortel as a proper hurd task in the task
> server.

Definitely not.  Wortel exists outside of the Hurd.  Think of wortel as a
primitive "manager OS".  What is sort of annoying is that wortel will have
very specific knowledge about the Hurd bootstrap procedure.  This is
not unavoidable, but to avoid it we would need a more abstract way to define
which boot modules belong together, and a "serverboot" like program that is
started by wortel which would then start physmem etc.  This is something
that one probably wants to do eventually, but it's totally useless to aim
for it at this stage.  For now, we can consider wortel to be a hybrid. 
Something outside of the Hurd that knows about the Hurd's needs.

> Then the task server would just mark the first few values for
> the taskid as "reserved".

In fact, wortel needs to tell the task server which task ids exist already
for physmem etc.  More importantly, it needs to tell it about the thread
ids already in use (and in the perspective of a manager OS, the thread ids
it is allowed to use).

> Threads with reserved ids, i.e. wortel,
> would then not be able to take part in the standard capability
> transfer protocol,

That's the plan anyway.


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

reply via email to

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