Runtime Modules & Boot Process

Developer
Dec 28, 2008 at 5:34 PM
Below is the start of an outline I've been writing this morning on the major modules in a CLR's runtime (e.g. the Virtual Execution System / VES). Please add / change / etc if you can think of other pieces, and I'll slot them where they should be. I have a knack for starting to forget pieces once I start writing them down.

--
MOSA Runtime
  Processes / Threads
  Exceptions?
  Asynchronous Operation Thread Pool
  File I/O
  Assembly Loading
    Cached Native Assembly Loader
    Bytecode Loader
      Bytecode Verifier
  Reflection
  Compiler Runtime Opcode Support
    call*
    new*
    box / unbox
  Base Class Library Connectors
    MethodImplAttribute
    MonoIO?

Also, below is my original writeup on a MOSA client OS's boot process. This is my current outline for Ensemble, actually. But it should start to show the differentiation we need to make between what services the compiler / runtime provide, versus what is really the OS's territory, and how everything should hook together. I'll be writing up a bigger outline, maybe a diagram (I'm horrible at those), after we get to a point of agreement.

==
GRUB loads platform-compiled Bootstrap Loader image

Bootstrap Loader
--
Bootstrap Loader starts
Init dummy page tables, etc
Switch to architecture native mode (32-bit, 64-bit, etc)
Load platform-compiled MOSA VES/Runtime
Load platform-compiled MOSA compiler
Pass IntPtrs (delegates?) of VES hooks into compiler
Pass IntPtrs of compiler trampolines, etc into VES
Perform VES Phase 1 initialization
  Prepares base classes, static exceptions (NPE, OOME, etc), verifier, etc
Have VES load CIL assemblies marked BootRequired on disk
  Assembly loading uses the BCL Assembly class, which ties into the VES, etc. Everything is handled like a "normal" assembly
Have VES load CIL assembly of Runtime Kernel
Call Runtime Kernel entrypoint method
  As this uses reflection from the BCL, which ties into the VES, the VES ends up calling the method in the normal CLR manner, looking up the method in the object method table. This points to the compiler trampoline, which compiles the entrypoint, and execution continues afterwards.

Runtime Kernel
--
Load assembly of platform HAL
Initialize processors
Initialize interrupts
  MOSA-Q: Set null pointer, breakpoint, etc system exception interrupt handlers to static VES exception throwers
Initialize PIT
Initialize page tables
  Pass IntPtr (delegate?) of memory allocation method into VES for use by newobj, etc processor
Initialize threading
  Pass IntPtr (delegate?) of thread creation method into VES
  Create process 0 / thread 0, init to current processor IP
Perform VES Phase 2 initialization
  Must create a delegate from IntPtr to Phase 2 init method, since VES is a platform-compiled binary?
  Prepares VES asynchronous operations thread pool
  Create compiler thread?
  Create garbage collector thread
Initialize security management
Initialize power management
Initialize IPC/RPC service registry
Search each of the BootRequired preloaded assemblies for a type decorated with the BootInit attribute
  Such assemblies include the driver framework, the VFS, network stack, etc
  Spawn threads for each assembly
    Call each type's BootInit attribute decorated static method
Load user interface CIL assembly
Spawn user interface thread
  Execute user interface assembly at entrypoint method (public static void Main()?)

Coordinator
Dec 28, 2008 at 6:50 PM
Scott, thanks for the outline. I'll try to write up my opinion tonight. However I'd like to split the description of VES/MOSA Runtime Modules and the booting process. This has three reasons: The first one is that MOSA will only provide a boot process recommendation and leave it mostly to those using our codebase, such as your Ensemble Project. The second reason is that the VES will not demand a specific booting procedure. And the third reason is that the VES will make some demands to the OS using it, e.g. how to acquire and use operating system services. I have a coarse design outlined for #1 and #3  and I'll try to describe both of these on our Wiki.

__grover
Developer
Dec 28, 2008 at 7:52 PM
Indeed, I probably screwed up a bit including both in one message
thread. The boot process was included as a reference point to our VES
discussion, as an example to show what's written by MOSA, and what's
left up to the OS projects.

In any case, your point #2 is slightly incorrect, because of #3. The
boot process I had, especially the two-phase VES initialization, is
because phase 2 init requires that certain OS services be up and running
- namely threading, for the async thread pool. Phase 1 inits just enough
of the VES to handle general "runtime/VM" things, so the proper managed
kernel can be booted. Everything else, dealing with threading, GC, FS
hooks, etc is left until phase 2, after the OS's kernel has been brought
up to speed.

I await the opinion response.

--S

__grover wrote:
>
> From: __grover
>
> Scott, thanks for the outline. I'll try to write up my opinion
> tonight. However I'd like to split the description of VES/MOSA Runtime
> Modules and the booting process. This has three reasons: The first one
> is that MOSA will only provide a boot process recommendation and leave
> it mostly to those using our codebase, such as your Ensemble Project.
> The second reason is that the VES will not demand a specific booting
> procedure. And the third reason is that the VES will make some demands
> to the OS using it, e.g. how to acquire and use operating system
> services. I have a coarse design outlined for #1 and #3 and I'll try
> to describe both of these on our Wiki.
>
> __grover
Coordinator
Jan 7, 2009 at 11:12 PM
I've written some bits of my kernel design thoughts on our MOSA-0003: Kernel and Process Model. Please discuss this in its discussion thread.