Task startup

[Niels Möller]

The current wortel sends each module a thread start message with an
initial instruction pointer and a zero stack pointer. Then the started
module sets up it's own statically allocated stack area.

The next step, in order to evolve towards a proper exec protocol must
be to have the creating task allocate an initial page for stack and
startup information. The creator prepares a page that contains startup
information, including

  reference to creator task (task server thread id, local id) 
  other capabilities        (thread id, local id)
  arguments                 (argv/argc/argz)

Then a stack area, where the first word points to the startup
information, and the initial value for the stack pointer is just below
this value. For the special case of startup from wortel, we don't have
a task server handle to the creator task, instead we have wortel's
thread id and the local id for the capability we have for access to
wortel.

The creator (wortel) , which is also the pager for the new thread, can
grant the initial stack page on the first page fault, just like it
grants all the code and data pages.

So the first very local win is that we can pass arguments to the
initial modules, and we can get rid of the hardcoded wortel thread id
and capability id that is done in physmem and task.

I write this to (i) explain how it's got to work, and (ii) try to
confirm that I haven't missed anything important. Some information is
in the exec section of Marcus' document, most important piece that
that's missing in my description above is the container handles for
the initial code and stack pages.

The short term roadmap as I see it (not sure if anybody else agrees
;-) is something like

  1. Implement some embryonic form of the startup protocol in wortel,
     physmem and task.

  2. Write a hello world module, and get wortel to start it by talking
     to the task server. The hello world module can be extended to
     test features in task and physmem as they are developed.

  3. Work on the capability library. As a side effect, we'll find out
     if and how the task server protocols are broken.

  4. Work on the physmem server, to get at least some embryonic form
     of containers.

Note that 1 and 2 are much simpler than 3 or 4, but I think they're
also fairly important for progress.

As a practical matter, I think it would help to create a small library
and a corresponding include file for wortel and related early modules.
It would contain definitions of the message labels and other magic
constant, client stubs for talking to wortel, and module startup code.

Best regards,
/Niels