startup code

[Johan Rydberg]

I've done some thinking about the whole startup code issue. With 
reservations for having misunderstood everything as usual, here goes:

The startup code is responsible for brining the program, or at least
parts of it, into memory before the real pager can take control. It 
also must allocate a new stack for the initial thread, and pass along 
information to the new pager when it is ready.

The question is where should most of the work be done: in the parent
or in the client [1], i.e. the startup code?

I argue that the startup code should be as small and simple as possible,
which means that most parts of the work must be done in the parent [2].

There is one main reason for this:

  It will make error detection easier.  What if there is something
  wrong with the program (invalid headers, ...) it can be detected
  in the parent, even before the new task is spawned.

This means that the parent process must do the actual parsing of the
program headers of the executable, and pass information about it to
the client.  If it sees that the program is a shell-script, it is
responsible for launching the interpreter.

But what information must be passed to the client?  Wrt getting the
program into memory, I think it should pass a set of sections, were
each section contains information about where in the virtual address
space the data should be located, a backing storage capability (file
that the data should be read from), and page range in the primary 
physmem container were the data should be stored.

In the case of a exec(), these sections should be constructed from the 
ELF-header.  In the case of a fork(), it will be constructed from the 
internal state of the pager.  The section must also contain a bitmap
that tells the pager which pages in the container actually contains data.
For a initial exec() this bitmap is empty, meaning that there is no
data at all in the container.  For fork(), it lists which pages hold
data and which should be brought into memory from the backing storage.

The parent must also pass the actuall entry point, so the startup code
knows how it should leave control to the real application.

There is also the special case for getting the bootstrap processes 
running.  This must be done by wortel, the rootserver.  Wortel should
use the same exec-protocol which is used by the real exec-implementation.

Wortel creates bootstrap containers for the bootstrap servers.  These
containers all the physical memory for the server.  Wortel passes section
information with the bitmap full, leting the startup code know that all
data is already in the container.

This eliminates the need for the physmem server to act as a backing 
storage server for the boostrap servers.

 [1] The new spawned process
 [2] The one doing the actuall spawning of the new process.  In the
     normal case it is the parent process, in the case of a suid-program
     it is the file system.

-- 
Johan Rydberg, Free Software Developer, Sweden
http://rtmk.sf.net | http://www.nongnu.org/guss/

Playing Koop - In A Heartbeat (Hird Remix)