Boot Process

This page is under construction. This page needs to be verified for validity.

• Microkernel is loaded by a multiboot-compliant boot loader
• Pick and set up a screen mode suitable for text output
• Call the architecture-dependent (ADC) init function
  • X86/IA32 Setup (SharpOS.ADC.X86.Arch.Setup)
    • Setup PIT
    • Setup PIC with stub first-level ISRs
    • Setup GDT
    • Setup LDT
      • Comment: How is the above affected for SMP / multicore? Can we add SMP now without too much (any?) pain, just for the heck of it? (TechGuy)
  • Setup the keymap system and pick a keymap (Keymap.Setup())
  • Setup the console system (Console.Setup())
• Setup memory page allocation (PageAllocator.Setup())
  • kernel passes it’s start/end and total memory determined by multiboot
  • allocates pages for the free page stack
  • allocates pages for the reserved page stack
  • allocates pages as requested by ADC.Pager.GetMemoryRequirements() for hardware paging support
  • reserves the above memory ranges using PageAllocator.ReservePageRange()
  • calls ADC paging setup, should set up a 1->1 memory map (ADC.Pager.Setup())
  • enables hardware paging (ADC.Pager.Enable())
  • fills the free page stack
• Setup memory byte range allocation (malloc/free) (MemoryManager.Setup())
  • Employs a growing/shrinking linked list of memory pages used for control data.
    • Comment: promotion of unmanaged objects to GCed objects: this needs discussion (xfury)
• Setup the runtime (Runtime.Setup())
  • Preload base classes (Object, Void, ValueType, etc. See Mono startup notes)
  • Prepare kernel AppDomain
  • Prepare GC / heap allocator (GC.Setup())
  • Somewhere in here, allocate VM stacks
  • Setup JIT engine
    • Setup IL verifier
    • Bytecode & object hierarchy (ensures casts are valid)
    • Local stack size
• Setup the scheduler core (EDC, SchedulerCore.Setup())
  • Allocate threading control data
  • Spawn JIT thread -> move JIT off to separate thread
  • Spawn concurrent GC threads -> Loads GC objects
  • Spawn device detection threads -> Loads device driver objects
• Setup the HAL
  • Either load the executable embedded in the kernel (Runtime.LoadProcess(void *addr)) or compile as EDC and use directly
  • detection of devices
  • registry of driver->device claims
  • Load and setup initial drivers/modules
    • Load modules embedded in kernel
      • Drivers claim devices
      • Plugin modules provide filesystem support
    • Load an initial root filesystem
      • Load a FS driver in the kernel (readonly)? (moitoius)
      • Load drivers/modules from init filesystem
  • Load real root filesystem
  • Load and execute first process as a userspace user (Admin?)

General notes

• new implementation for EDC can be a dummy in the early boot stages, using MemoryManager.Alloc (with a ‘PromoteGC’ flag), with the buffer prefixed with an object type ID. When the GC initializes, MemoryManager provides it with the information necessary to move them over.
• typeof / runtime reflection is usually handled by having runtime-level object headers, such as how a normal OS has page descriptors at the start of a page, space descriptors written by malloc, etc
• why must EIC be structs instead of classes with unsafe methods?
  • we only use static methods during init, so struct vs. class (stack vs. heap) doesn’t matter?
• Need to determine:
  • internal representation of object in heap
  • internal representation of thread
  • internal representation of AppDomain / process