## XTOSKRNL
XTOSKRNL is the core kernel executable for ExectOS, providing the fundamental kernel and executive layers that operate
within the XTOS kernel space. It is responsible for various core services, such as hardware abstraction, memory
management, and process scheduling. The kernel contains the scheduler (sometimes referred to as the Dispatcher), the
cache, object, and memory managers, the security manager, and other executive components described below.


## Kernel Parameters
Kernel parameters are XTOS boot-time options used to ensure proper initialization and handling of hardware peripherals.
These parameters can be configured either temporarily by editing the boot entry in the bootloader’s selection menu, or
permanently by modifying the XTLDR configuration file.

The following is a consolidated list of available kernel parameters:
 * **CLOCK**: Specifies the primary hardware source used to drive the periodic system clock interrupts and the thread
   scheduler tick. Valid values include `LAPIC` (Local APIC Timer), `HPET` (High Precision Event Timer), and `PIT`
   (Legacy Programmable Interval Timer). If this parameter is omitted, the kernel will autonomously probe the hardware
   and select the most optimal clock source for the current CPU topology, (defaulting to the Local APIC on modern systems.
 * **MAXCPUS**: Specifies the maximum number of logical processors the kernel is allowed to initialize and schedule.
   Setting `MAXCPUS=1` explicitly disables Symmetric Multiprocessing (SMP), restricting execution exclusively to the Boot
   Strap Processor (BSP) and ignoring all Application Processors (APs).
 * **NOX2APIC**: Explicitly disables x2APIC support. When specified, the kernel bypasses hardware feature detection for
   x2APIC and forces the use of the classic, memory-mapped (MMIO) xAPIC mode. This parameter is particularly useful for
   troubleshooting interrupt routing issues or ensuring compatibility with specific hypervisors and legacy emulators.
 * **NOXPA**: Disables PAE or LA57 support, depending on the CPU architecture. This parameter is handled by the
   bootloader, which configures paging and selects the appropriate Page Map Level (PML) before transferring control to
   the kernel.
 * **TIMER**: Designates the hardware counter used for high-resolution performance tracking (Query Performance Counter)
   and microsecond execution stalls. Valid values include `TSC` (Invariant Time Stamp Counter), `HPET`, `ACPI` (or `PM`)
   for the ACPI Power Management Timer, and `PIT`. If not specified, the kernel evaluates hardware capabilities and
   defaults to the most precise and reliable counter available (e.g., Invariant TSC).

## Source Code
The source code of the kernel is organized into subsystem-specific directories. Each directory name also defines the
corresponding C++ namespace in which the subsystem's classes and routines reside. These subsystems include:

 * Ar - Architecture-specific Library
 * Ex - Kernel Executive
 * Hl - Hardware Layer
 * Kd - Kernel Debugger
 * Ke - Core Kernel Library
 * Mm - Memory Manager
 * Po - Plug&Play and Power Manager
 * Ps - Process and Thread Manager
 * Rtl - Runtime library

### AR: Architecture Library
This module contains functions specific to the processor architecture. These include routines for enabling and disabling
interrupts, retrieving the faulting address on a page fault, querying CPUID information, and performing very early
processor initialization. This module contains only CPU architecture-specific code, with no manufacturer or
board-specific implementations.

### EX: Kernel Executive
The Kernel Executive provides services for allocating system memory from paged and non-paged pools. It also supplies
synchronization primitives such as pushlocks and fast mutexes, routines for interlocked memory access, and support for
worker threads.

### HL: Hardware Layer
The Hardware Layer is an abstraction layer between the physical hardware and the rest of the operating system. It is
designed to abstract away hardware differences, providing a consistent platform on which the kernel and applications
can run.

### KD: Kernel Debugger
The Kernel Debugger (KD) subsystem provides debugging support for the kernel. The KD is initialized early in the boot
process to facilitate debugging from the very beginning of the kernel's execution.

### KE: Kernel Library
The Core Kernel Library implements the core functionality upon which the rest of the system depends. This includes
fundamental low-level operations, such as routing hardware interrupts and managing dispatcher objects.

### MM: Memory Manager
The Memory Manager is one of the core subsystems. It manages virtual memory, controls memory protection, and
handles paging memory between physical RAM and secondary storage. It also implements a general-purpose allocator for
physical memory.

### PO: Plug&Play and Power Manager
This subsystem handles power management events, such as shutdown or standby. It also manages Plug and Play (PnP),
supporting device detection and installation at boot time. Furthermore, it is responsible for starting and stopping
devices on demand.

### PS: Process and Thread Manager
This subsystem is responsible for managing the lifecycle of processes and threads within the operating system. It
handles the creation, termination, and state tracking of these execution units. Furthermore, it provides the high-level
executive abstractions required to allocate system resources, manage process boundaries, and coordinate with the core
kernel for thread execution.

### RTL: Runtime Library
The Runtime Library provides a kernel-mode implementation of common C library functions. It includes many utility
routines, for use by other kernel components.

## Function Naming Convention
All kernel functions adhere to a strict naming convention to enhance code readability and maintainability. The structure
of all public interfaces exposed by the kernel are generally composed of three parts:
&lt;Prefix&gt;&lt;Operation&gt;&lt;Object&gt;

The prefix identifies the component to which the function belongs. For example, consider the **KeInitializeThread()**
routine:
 * **Ke** - The prefix indicates a routine belonging to the Core Kernel Library (Ke).
 * **Initialize** - The operation performed by the function.
 * **Thread** - The object on which the operation is performed.

For all C++ code inside the kernel the naming model has evolved. Consider the **KE::KThread::InitializeThread()**
routine:
 * **KE** - The namespace replaces the prefix and indicates the subsystem. Namespaces are written in uppercase and no
   longer use the trailing p for private routines, because classes use C++ visibility to control access.
 * **KThread** - Within each namespace, related functionality is grouped into classes, which encapsulate variables and
   methods.
 * **InitializeThread** - Method names follow the `<Operation><Object>` pattern.
 