This page outlines a 10,000 foot technical view of the Minoca OS kernel architecture. If you came here looking for a list of features, check out the Product page.

The Minoca kernel is written almost entirely in C, with snippets of assembly used only sparingly. The kernel itself is monolithic in style, but is built by combining several system libraries that each observe a well-defined API. Though Minoca OS supports POSIX applications and therefore many Unix-style constructs, the kernel was written entirely from scratch and contains no code from Unix, Linux, or any other *nix variant. Below is a list of the major system libraries that are compiled together to form the complete Minoca OS kernel. The letters in parentheses represent the prefix added to all C function names in the given module.

  • Kernel Executive (Ke) - The kernel executive is responsible for the higher brain functions of the operating system. It manages system time, thread scheduling, Deferred Procedure Calls (DPCs), software timers, and Inter-Processor Interrupts (IPIs).

  • Hardware Layer (Hl) - At the opposite end of the spectrum from the executive is the hardware layer. This module is responsible for abstracting the low level built-in hardware of the system. It's role is to prevent the other libraries from containing hardware specific code. The hardware layer manages hardware timers, calendar timers, interrupt controllers, DMA, and cache controllers. It also plays a heavy role in processor enumeration, processor startup, interrupt processing, and interrupt distribution.

  • Architecture Library (Ar) - This module contains processor architecture specific functions. This includes enabling and disabling interrupts at the processor, getting the address of a page fault, getting CPUID information, and performing very early processor initialization. This module does not contain any manufacturer or board-specific code, only CPU architecture specific code. There is very little logic in this library, most of the functions are simple routines that provide access to architectural registers.

  • Input/Output Library (Io) - The I/O library provides the API for working with devices and drivers. It is the largest module in the kernel. It manages the device tree, device drivers, device enumeration, I/O requests (IRPs), and resource arbitration. When applications call functions like read() and write(), it is the I/O library coordinating the activity between the right drivers and file systems.

  • Memory Manager (Mm) - This module manages everything to do with memory. It is the ultimate source of virtual and physical memory in the OS, including the paged and non-paged pools. The memory manager integrates closely with the I/O library to provide support for functions like mmap() and swapping pages to disk.

  • Process and Thread Library (Ps) - This module manages the process and thread life cycle. It coordinates the creation and destruction of processes and threads, as well as the inter-process signaling facilities that back POSIX functions like kill() and signal().

  • Object Manager (Ob) - This module manages a global object tree. Other libraries make use of various branches in the global object tree. For example, processes and threads are represented as objects underneath the /Process subtree, the system device tree is installed off of /Device, and file system volumes can be found in the /Volume subtree. In fact, the ultimate root of the file system hierarchy is the object manager itself.

  • Image Library (Im) - This helper library provides binary image support for formats such as ELF. It is responsible for reading an image off of disk and mapping it into memory, as well as loading any dependent binaries. The Im library is modularized in such a way that in addition to being part of the kernel, it is actually compiled into the boot loader and image tools as well.

  • Runtime Library (Rtl) - The runtime library provides support for basic functions like string formatting, zeroing memory, and some generic data structures. The runtime library is also compiled into user mode, and does the heavy lifting for many C library functions like vsprintf() and vsscanf(). Since standard C library functions like memset and printf are not available in the kernel, the Rtl library provides equivalent functionality for the kernel and drivers.

  • Kernel Debugger (Kd) - This small library allows a running kernel to be halted, stepped, examined, and debugged by a remote machine over a serial port. It's functioning is largely invisible, even to developers. Code in this library is generally considered sacred, as tracking down bugs in the library that provides debugging support can be difficult and tedious.

  • System Profiler (Sp) - The system profiler library works in concert with the Kd library to provide performance profiling of the kernel. It can send kernel-mode stack sampling, memory consumption, and thread statistics across the debug channel to a remote machine for real-time analysis.