Rewrite and clarify kernel subsystem descriptions

xtoskrnl/README.md

@@ -1,58 +1,68 @@
 ## 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
  * 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
  * Rtl - Runtime 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
-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
-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
-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
-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
-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
-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.