feat: Heavily reworked the SMP subsystem paper.

refactor: BinaryMutex implementation and paper has been reworked as
well using LockAndWait instead of LockOrWait.
other: Reworked tooling macros.

Signed-off-by: Amlal El Mahrouss <amlal@nekernel.org>

4 files changed, 20 insertions, 15 deletions

diff --git a/docs/tex/NOTICE.md b/docs/tex/NOTICE.md
index 5d6eb03f..c4015afd 100644
--- a/docs/tex/NOTICE.md
+++ b/docs/tex/NOTICE.md
@@ -1,5 +1,6 @@
-# Notice for LaTeX documents.
+# Notice
 
-## Recommended Tool
+## Recommended:
 
-`pdflatex` is recommended for this matter, although you are free to use other tools.
+- `pdflatex` is recommended for this matter.
+- You can use `overleaf` to edit the LaTeX files too.
\ No newline at end of file
diff --git a/docs/tex/binary_mutex.tex b/docs/tex/binary_mutex.tex
index 9b8a1c40..1b5a59c2 100644
--- a/docs/tex/binary_mutex.tex
+++ b/docs/tex/binary_mutex.tex
@@ -51,7 +51,7 @@ class BinaryMutex final {
 
  public:
   bool Lock(USER_PROCESS* process);
-  bool LockOrWait(USER_PROCESS* process, TimerInterface* timer);
+  bool LockAndWait(USER_PROCESS* process, TimerInterface* timer);
 
  public:
   NE_COPY_DEFAULT(BinaryMutex)
diff --git a/docs/tex/nefs.tex b/docs/tex/nefs.tex
index 7f2fdd84..37e43d13 100644
--- a/docs/tex/nefs.tex
+++ b/docs/tex/nefs.tex
@@ -21,9 +21,9 @@
   showstringspaces=false
 }
 
-\title{NeFS: New Extended File System}
+\title{NeFS: New Extended File System Specification}
 \author{Amlal El Mahrouss}
-\date{\today}
+\date{2025}
 
 \begin{document}
 
diff --git a/docs/tex/nekernel_smp_subsystem.tex b/docs/tex/nekernel_smp_subsystem.tex
index 9a5fe776..cb30f3cb 100644
--- a/docs/tex/nekernel_smp_subsystem.tex
+++ b/docs/tex/nekernel_smp_subsystem.tex
@@ -7,22 +7,26 @@
 
 \begin{document}
 
-\maketitle
+    \maketitle
 
-\section{Abstract}
+    \section{Abstract}
 
-{NeKernel is a hybrid based operating system kernel written in modern C++ (C++17/C++20). It features a bootloader, kernel, tools, libraries, and frameworks. This document is about the SMP subsystem of NeKernel}
+    {NeKernel is a hybrid based operating system kernel written in modern C++ (C++17/C++20). It features a bootloader, kernel, tools, libraries, and frameworks. This document is about the SMP subsystem of the kernel.}
 
-\section{Design Overview}
+    \section{Design Overview}
 
-ne\_kernel is designed with SMP by default. Although it may fallback under classic preemptive round-robin scheduling when unavailable - NeKernel runs best on a SMP based machine. The subsystem goes from the HardwareThreadScheduler to the Hardware Abstraction Layer's Application Processors API.
+    {NeKernel is designed with SMP by default. Although it may fallback under classic preemptive round-robin scheduling when unavailable - NeKernel runs best on a SMP based machine. The subsystem goes from the HardwareThreadScheduler to the Hardware Abstraction Layer's Application Processor API.}
 
-\subsection{HardwareThreadScheduler (HTS)}
+    \section{The SMP Subsystem}
 
-HardwareThreadScheduler's main purpose is to make cores all busy with a StackFrame. That StackFrame contains program information (instruction, stack pointers) each task is fairly assigned to a core to then be run by the Application Processors API.
+    {The SMP subsystem consist of the HTS (HardwareThreadScheduler) and AP (Application Processor) APIs. Those systems are made to handle SMP tasks inside NeKernel.}
 
-\subsection{Application Processors (AP)}
+    \subsection{Higher Level: HardwareThreadScheduler (HTS)}
 
-Application Processors (now referred as AP) is the API taking care of multi-core scheduling, very platform dependent (thus its presence on the HAL) it is designed to run tasks passed from the HardwareThreadScheduler system.
+    {HTS's main purpose is to make cores all busy with a StackFrame object. That object contains program registers such as the stack pointer and instruction pointer. Each task is fairly assigned to then be run by the AP's mp\_register\_task function.}
+
+    \subsection{Lower Level: Application Processor (AP) API}
+
+    {Application Processors (now referred as AP) is the API taking care of multi-core scheduling, very platform dependent (thus its presence on the HAL) it is designed to run tasks passed from the HTS.}
 
 \end{document}