Dec 28, 2008 at 6: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.
Processes / Threads
Asynchronous Operation Thread Pool
Cached Native Assembly Loader
Compiler Runtime Opcode Support
box / unbox
Base Class Library Connectors
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 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
Load assembly of platform HAL
MOSA-Q: Set null pointer, breakpoint, etc system exception interrupt handlers to static VES exception throwers
Initialize page tables
Pass IntPtr (delegate?) of memory allocation method into VES for use by newobj, etc processor
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()?)
Dec 28, 2008 at 7: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.
Dec 28, 2008 at 8: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.
> 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.
Jan 8, 2009 at 12:12 AM
I've written some bits of my kernel design thoughts on our
MOSA-0003: Kernel and Process Model. Please discuss this in its