xt-sys/exectos
3
5
Fork 2
Code Issues 3 Pull Requests 1 Actions Projects 1 Releases Wiki Activity

Update readme to reflect C++ namespaces and class-based naming
All checks were successful
Builds / ExectOS (amd64, release) (push) Successful in 27s
Details
Builds / ExectOS (amd64, debug) (push) Successful in 29s
Details
Builds / ExectOS (i686, debug) (push) Successful in 28s
Details
Builds / ExectOS (i686, release) (push) Successful in 26s
Details

Browse Source
This commit is contained in:
Aiken Harris
2025-09-23 22:54:41 +02:00
parent 6e10089280
commit 20fd950ef4
1 changed files with 17 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
xtoskrnl/README.md
View File

@@ -4,8 +4,8 @@ within the XTOS kernel space. It is responsible for various core services, such
management, and process scheduling. The kernel contains the scheduler (sometimes referred to as the Dispatcher), the 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. cache, object, and memory managers, the security manager, and other executive components described below.
All routines in the kernel are prefixed to indicate the subsystem they belong to, and their source code is organized The source code of the kernel is organized into subsystem-specific directories. Each directory name also defines the
into corresponding directories. These subsystems include: corresponding C++ namespace in which the subsystem's classes and routines reside. These subsystems include:
* Ar - Architecture-specific Library * Ar - Architecture-specific Library
* Ex - Kernel Executive * Ex - Kernel Executive
@@ -56,13 +56,20 @@ routines, for use by other kernel components.
## Function Naming Convention ## Function Naming Convention
All kernel functions adhere to a strict naming convention to enhance code readability and maintainability. The structure All kernel functions adhere to a strict naming convention to enhance code readability and maintainability. The structure
of a function name is generally composed of three parts: <Prefix><Operation><Object> of all public interfaces exposed by the kernel are generally composed of three parts:
<Prefix><Operation><Object>
The prefix identifies the component to which the function belongs. Additionally, the prefix indicates the function's The prefix identifies the component to which the function belongs. For example, consider the **KeInitializeThread()**
visibility. Private functions, which should not be called from outside their own module, have a 'p' appended to their routine:
prefix. * **Ke** - The prefix indicates a routine belonging to the Core Kernel Library (Ke).
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. * **Initialize** - The operation performed by the function.
* **Stack** - The object on which the operation is performed. * **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.