Re: [Hurd-alpha-devel] Re: L4 instead of gnumach?

[Niels Möller]

Ad Buijsen <address@hidden> writes:

> Those gurus can be found on the L4 hackers list.
> 
> 64 Threads and 128 tasks....looks like an implementation for embedded
> systems.

Hmm, I'm also new to this, but some thoughts below. I'm trying to ask
the right questions, in the hope that someone will tel me if I'm on
track or not, and what the l4 gurus' approach to these problems are.
They can't be new or unique to the l4-hurd effort.

Is there any way for a user-level process (e.g. a user-level
scheduler) to save and restore the state of a task? Then one could
keep a small number of tasks ready to run, and freeze the other ones
just keeping their state in a single separate swapping task. I.e.
mapping the processes onto a limited number of l4 tasks, just as with
threads. 

Hmm, perhaps one can have a thread in each active task that is trying
to send a message to the scheduler (with infinite timeout). The
message should consist of the entire mapping of the task, and
information about the state of each of its threads. The
scheduler/swapper receives this message (with a short timeout) when it
decides to swap out the task. Or if one doesn't have a big enough
address space to receive the entire mapping for each swapped out
process, one would have to do something more complex.

One tricky part here is probably to get hooks into ipc that handles
ipc to threads or tasks that are not currently mapped to a real l4
thread or task. Is there a way to have a special clan consisting of
all the currently unmapped threads? A chief for that clan might be
able to do some magic.

What will happen with thread "uid":s for threads in processes that are
swapped in and out of the l4 task space? I guess the uid "version
number" comes in here in some way.

Anouther tricky part, I guess, will be to get really good performance
in the common case (active threads talking to other active threads),
and still get the other cases to work slower but transparently.

/Niels