
                 Boot sequence of the Fiasco Microkernel

               Alexander Warg  <aw11@os.inf.tu-dresden.de>

                               7 April 2003


The coarse sequence
-------------------

The final Fiasco image (called 'fiasco') is build of two parts, the
'BOOT' subsystem and a raw ELF image of the Fiasco kernel linked into
the data section. The BOOT subsystem is responsible for loading the
linked-in ELF image of the actual kernel, to set up the initial
mappings, and transfer control to the virtual-addressed entry point of
the ELF image. After the kernel gained control it runs the boot
sequence described in the following section.

The detailed Fiasco-kernel boot sequence
----------------------------------------

1. control is transfered to the entry point of the ELF image (normally
   '_start' defined in 'crt0.S') 

   - crt0.S is architecture specific code and located in
     src/kern/$(ARCH)

2. crt0.S sets up an initial stack and calls the C-function '__main'.

3. __main, which is defined in '__main.cpp', does the following: 
   - registers 'static_destruction' via 'atexit' to be called on 
     shutdown 
   - runs all C++ constructors (see C++ boot sequence for more 
     information) via 'static_construction()'
   - transfers control to 'main'; at this point normal C execution 
     starts, all static constructors, which are specified via 
     STATIC_INITIALIZE{R}{_P} are executed.

4. main: does some IRQ controller setup, creates the initial kernel
   thread, which later becomes the idle thread, switches to to its
   stack, and calls 'Kernel_thread::bootstrap'.


C++ boot sequence
-----------------

The Fiasco kernel uses C++ static construction mechanisms for its
boot sequence. The file 'static_init.h' contains some crude macro
magic to declare functions and classes to be initialized via C++
static constructors. These constructors are called in a specific order
from static_construction, which is called from __main. 

The described static C++ constructors should be used only for dynamic
components, which can be plugged in or left out at link time. One
exception is 'startup()'; 'startup()' is defined in 'startup.cpp' and
runs with the highest constructor priority, thus runs as the very
first constructor. In 'startup' all boot-time non-dynamic
initialization functions are called in the right order (just take a
look at 'startup.cpp').
