Unify and simplify component initialization functions

[gparmer]

The Problem

Currently, if a low-level component uses the cos_defkernel_api, it must perform initialization (before running anything else) via

• cos_meminfo_init
• cos_defcompinfo_init and
• cos_hw_cycles_per_usec

If the component is parallel, then each other core must execute

• cos_defcompinfo_sched_init

If it uses the cos_kernel_api, there a different initialization function. If it uses sl, there is sl_init. And so on, so forth...

This is all kind of a mess.

Classifying Components and Initialization Requirements

I observe that components have three flavors relevant to this issue:

1. A component that uses crt or the cos_kernel_api and manages system resources, and delegates them. It requires access to its own resource tables, and allocates its own resources (from its untyped memory).
2. Components that need to manage resources, but not allocate them. Schedulers are the main example of this class. They don't need all of the capability slots populated (e.g. not the ones references its own resource tables), but they do need references to threads, tcaps, and receive resources.
3. Normal components that have access only to a. synchronous invocation callgates, b. asynchronous activation end-points, and c. receive end-points.

(1) must initialize all data-structures that hold the default capability layout and initialize the execution resources. (2) must initialize only the data-structures that have to do with thread and execution behaviors, and (3) don't need to do any initialization at all.

Is there any way to do all of this automatically?

Proposed Solution

Though they are ugly, constructors are likely the cleanest solution here. We could create a set of constructor priorities above those that already exist that would capture the following control flow:

• component class (1) initialization (executing multiple functions)
• component class (2) initialization for the current initialization core
• libc initialization
• normal constructors (i.e. __attribute__((constructor)) and c++ constructors)
• cos_init
• component class (1) & (2) parallel initialization for execution resources on other cores
• cos_parallel_init
• main or parallel_main

Then we need some way, in each initialization function, to only initialize resources they should. If this is an issue, then the initial arguments will need to pass if we are of class (1), (2), and/or (3).