eersoy93/exectos
1
0
Fork 0
forked from xt-sys/exectos
Code Pull Requests Activity

Rewrite and clarify kernel subsystem descriptions

Browse Source
This commit is contained in:
Aiken Harris 2025-09-04 11:16:03 +02:00
parent 7e039c47ae
commit 8898a427df
Signed by: harraiken
GPG Key ID: C40F06CB7493C1F5
1 changed files with 46 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

82
xtoskrnl/README.md
View File

@ -1,58 +1,68 @@
## XTOSKRNL ## XTOSKRNL
XTOSKRNL is an XT system kernel executable, providing the kernel and executive layers for XTOS kernel space. It is XTOSKRNL is the core kernel executable for ExectOS, providing the fundamental kernel and executive layers that operate
a fundamental part of ExectOS, responsible for various core services like hardware abstraction or memory management. within the XTOS kernel space. It is responsible for various core services, such as hardware abstraction, memory
This kernel, contains the scheduler (called sometimes as Dispatcher), cache, object and memory managers, security management, and process scheduling. The kernel contains the scheduler (sometimes referred to as the Dispatcher), the
manager and other kernel executives described below. cache, object, and memory managers, the security manager, and other executive components described below.
All routines in kernel are prefixed to indicate the kernel subsystem they belong and put inside separate directory. All routines in the kernel are prefixed to indicate the subsystem they belong to, and their source code is organized
This is a list of them: into corresponding directories. These subsystems include:
* Ar - Architecture library * Ar - Architecture-specific Library
* Ex - Kernel Executive * Ex - Kernel Executive
* Hl - Hardware Layer * Hl - Hardware Layer
* Ke - Core kernel library * Kd - Kernel Debugger
* Mm - Memory manager * Ke - Core Kernel Library
* Mm - Memory Manager
* Po - Plug&Play and Power Manager * Po - Plug&Play and Power Manager
* Rtl - Runtime library * Rtl - Runtime library
### AR: Architecture Library ### AR: Architecture Library
This module contains processor architecture specific functions. This includes enabling and disabling interrupts at This module contains functions specific to the processor architecture. These include routines for enabling and disabling
the processor, getting the address of a page fault, getting CPUID information, and performing very early processor interrupts, retrieving the faulting address on a page fault, querying CPUID information, and performing very early
initialization. This module does not contain any manufacturer or board-specific code, only CPU architecture specific processor initialization. This module contains only CPU architecture-specific code, with no manufacturer or
code. board-specific implementations.
### EX: Kernel Executive ### EX: Kernel Executive
The kernel executive supplies heap management, including support for allocating system memory from paged/non-paged The Kernel Executive provides services for allocating system memory from paged and non-paged pools. It also supplies
pools, as well as synchronization primitives like push locks and fast mutexes, interlocked memory access, and worker synchronization primitives such as pushlocks and fast mutexes, routines for interlocked memory access, and support for
threads. worker threads.
### HL: Hardware Layer ### HL: Hardware Layer
Hardware Layer, is a layer between the physical hardware of the computer and the rest of the operating system. It was The Hardware Layer is an abstraction layer between the physical hardware and the rest of the operating system. It is
designed to hide differences in hardware and therefore it provides a consistent platform on which the system and designed to abstract away hardware differences, providing a consistent platform on which the kernel and applications
applications may run. 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 ### KE: Kernel Library
The kernel implements its core functionality that everything else in the system depends upon. This includes basic The Core Kernel Library implements the core functionality upon which the rest of the system depends. This includes
low-level operations such as routing hardware interrupts. fundamental low-level operations, such as routing hardware interrupts and managing dispatcher objects.
### MM: Memory Manager ### MM: Memory Manager
Memory Manager is one of core subsystems. It manages virtual memory, controls memory protection and the paging of memory The Memory Manager is one of the core subsystems. It manages virtual memory, controls memory protection, and
in and out of physical memory to secondary storage. It also implements a general-purpose allocator of physical memory. 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 ### PO: Plug&Play and Power Manager
This subsystem deals with power events, such as power-off, stand-by, or hibernate. It also handles Plug&Play and This subsystem handles power management events, such as shutdown or standby. It also manages Plug and Play (PnP),
supports device detection and installation at boot time. It is responsible for starting and stopping devices on demand. supporting device detection and installation at boot time. Furthermore, it is responsible for starting and stopping
devices on demand.
### RTL: Runtime Library ### RTL: Runtime Library
This is a required static copy of C runtime objects. It includes many utility functions that can be used by native The Runtime Library provides a kernel-mode implementation of common C library functions. It includes many utility
applications. routines, for use by other kernel components.
## Functions Naming Convention ## Function Naming Convention
When naming a kernel functions, certain conventions are used. The function name is usually structured with All kernel functions adhere to a strict naming convention to enhance code readability and maintainability. The structure
<Prefix><Operation><Object>. The prefix denotes the module to which it belongs, thus module of a function name is generally composed of three parts: <Prefix><Operation><Object>
can be identified simply by the name of the function. Additionally, the prefix identifies the function visibility
as well. Thus all private functions, that should not be used from outside of the module has added "p" suffix to The prefix identifies the component to which the function belongs. Additionally, the prefix indicates the function's
the prefix. For example, KepInitializeStack() routine: visibility. Private functions, which should not be called from outside their own module, have a 'p' appended to their
* Kep - prefix meaning this is private routine belonging to Kernel library (Ke) module, prefix.
* Initialize - operation this function does with the object,
* Stack - the object is stack. For example, consider the **KepInitializeStack()** routine:
* **Kep** - The prefix indicates a private (p) routine belonging to the Core Kernel Library (Ke).
* **Initialize** - The operation performed by the function.
* **Stack** - The object on which the operation is performed.