chore: new fixed WG01 and WG02 papers.

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

4 files changed, 48 insertions, 93 deletions

diff --git a/papers/wg01/wg01.pdf b/papers/wg01/wg01.pdf
deleted file mode 100644
index 5813a3b..0000000
--- a/papers/wg01/wg01.pdf
+++ /dev/null
diff --git a/papers/wg02/wg02.pdf b/papers/wg02/wg02.pdf
deleted file mode 100644
index b924cde..0000000
--- a/papers/wg02/wg02.pdf
+++ /dev/null
diff --git a/source/wg01/wg01.tex b/source/wg01/wg01.tex
index f194c27..f796ce9 100644
--- a/source/wg01/wg01.tex
+++ b/source/wg01/wg01.tex
@@ -1,5 +1,5 @@
 % AUTHOR: Amlal El Mahrouss
-% PURPOSE: WG01: Kernel C++
+% PURPOSE: Kernel C++: A Methodology for Freestanding Development
 
 \documentclass[11pt, a4paper]{extarticle}
 \usepackage{graphicx}
@@ -15,7 +15,7 @@
 \definecolor{codegreen}{rgb}{0,0.6,0}
 \definecolor{codepurple}{rgb}{0.58,0,0.82}
 
-\title{WG01: Kernel C++: A Methodology for Freestanding Development}
+\title{Kernel C++: A Methodology for Freestanding Development}
 \author{Amlal El Mahrouss}
 \date{December 2025}
 
@@ -51,22 +51,21 @@
 \end{center}
 
 \abstract{
-Many Operating Systems Kernels have been shipped using the C programming language.
-And some of them like EKA2 use the C++ programming language. Although notoriously difficult, one may still adapt to those constraints in order to deliver one such operating system kernel.
-That is the reason that most production-grade kernels (Linux, XNU, and NT) are mostly written in C. With a higher-level subset in C++.
-However, when correctly applying C++ principles to kernel development, one makes the development much more easier to pull off.
+Many Operating Systems kernels have been shipped using the C programming language.
+And some of them like EKA2 use the C++ programming language. Although notoriously difficult, one may adapt to those constraints in order to deliver one such operating system kernel.
+This is why most production-grade kernels (Linux, XNU, and NT) are mostly written in C. With a higher-level subset in C++.
+However, when correctly applying C++ principles to kernel development, it becomes much easier to pull off.
 }
 
 \section{The Three Principles of Kernel C++.}
 \subsection{Part One: The C++ Runtime.}
 {
-The problem mostly lies in the C++ runtime. Which assumes an existing host. A host is the contrary of a freestanding target, that is a program which expects a runtime to be present and linked to the program.
-A C++ Kernel may instead make use of compile-time features of C++ alongside a tiny C++ runtime to make sure that no issues arise because of this host/freestanding difference.
+The problem lies in the C++ runtime, which assumes an existing host. The contrary of a hosted environment, freestanding, is a runtime which doesn't expect a hosted runtime. Such freestanding target may make use of compile-time evaluation of the C++ programming alongside a minimal C++ runtime to write such programs.
 }
 
-\subsection{Part Two: Constexpr and Friends.}
+\subsection{Part Two: Compile-Time Evaluation.}
 {
-One may avoid Virtual Method Tables or a Runtime when possible. While focusing instead on meta-programming and compile-time features offered by C++. 
+One may avoid Virtual Method Tables or a runtime when possible. While focusing instead on meta-programming and compile-time features offered by C++. 
 For example one may use templates to implement a scheduling policy algorithm.
 One example of such implementation may be:
 
@@ -90,46 +89,11 @@ struct MemoryTree final {
     static constexpr bool is_file = false;
     /// ...
 };
-\end{lstlisting}
-
-As you see, two structures leverages the `constexpr' keyword to make sure
-no bugs or panic occur at runtime because of a misuse of a system resource.
-
-Which is why the constexpr keyword is very powerful here, we avoid the many pitfalls of writing (and hoping) that the C version will be well-thought enough so that we can catch such bugs later.
-
-\subsection{Bonus: Using Concepts and the DDK.}
-{
-This bonus subsection intends to show how properly applied C++\\
-Can solve issues related to driver validation.
-The following example shows how powerful C++ can be when combining it with Device Driver development as well.
-
-\begin{lstlisting}
-/// Reference implementation:
-/// https://github.com/nekernel-org
-/// /nekernel/blob/stable/src/libDDK/DriverKit
-/// /c%2B%2B/driver_base.h
-/// @brief This concept requires the driver 
-/// to be IDriverBase compliant.
-
-inline constexpr auto kInvalidType = 0;
-
-template <class Driver>
-concept IsValidDriver = requires(Driver drv) {
-  { drv.IsActive() && drv.Type() > kInvalidType };
-};
-
-/// @brief Consteval helper to detect
-/// whether a template is truly based on IDriverBase.
-/// @note This helper is consteval only.
-template<IsValidDriver T>
-consteval void ce_ddk_is_valid(T) {}
-\end{lstlisting}
-}
-}
+\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/stable/src/kernel/KernelKit/CoreProcessScheduler.h#L78-L105}{https://github.com/nekernel-org/nekernel/blob/stable/src/kernel/KernelKit/CoreProcessScheduler.h} Which is why the `constexpr' keyword is very powerful here for the Compile-Time Evaluation Domain, we avoid the many pitfalls of the Run-Time Evaluation Domain.
 
 \subsection{Part Three: Memory and C++ Classes.}
 {
-This last part treats about the final and most important part of this paper so far. Memory. As you may already have known, the C++ language uses a class lookup system also called a VMT (Virtual Method Table) in order to refer to a base method in case if the instance has it missing.
+The Virtual Method Table (now defined as the VMT) is a big part of the problem, one may illustrate the following:
 
 \begin{lstlisting}
 /// Link: https://godbolt.org/z/aK6Y98xnd
@@ -160,53 +124,46 @@ int main() {
     B callImpl;
     callImpl.doImpl();
 }
-\end{lstlisting}
+\end{lstlisting} The following can instead be done to achieve similar results using the Compile-Time Evaluation Domain.
+
+\begin{lstlisting}
+/// Reference implementation:
+/// https://github.com/nekernel-org
+/// /nekernel/blob/stable/src/libDDK/DriverKit
+/// /c%2B%2B/driver_base.h
+/// @brief This concept requires the driver 
+/// to be IDriverBase compliant.
+
+inline constexpr auto kInvalidType = 0;
 
-\section{Addressing VMTs in a C++ Kernel.}
+template <class Driver>
+concept IsValidDriver = requires(Driver drv) {
+	{ drv.IsActive() && drv.Type() > kInvalidType };
+};
 
-Now the problem with kernel development is that we want to avoid such feature as much as possible,
-and we'd do that by following the Prong on Inheritance:
+template<IsValidDriver T>
+consteval void ce_ddk_is_valid(T) {}
+\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/stable/src/libDDK/DriverKit/c%2B%2B/driver_base.h}{https://github.com/nekernel-org/nekernel/blob/stable/src/libDDK/DriverKit/c\%2B\%2B/driver\_base.h} Now, the problem with freestanding development is that such feature may be abused, and it is mitigated by following the TTPI.
 
 \subsection{The Three Prongs on Inheritance Decision Framework.}
 
-TTPI is a boolean framework used to evaluate whether one may consider using C++ in a kernel. Consider the following:
+The TTPI is a boolean framework used to evaluate whether one may consider using C++ in a kernel, consider the following:
 
 \begin{itemize}
-\item[1:] Is this a feature that can be implemented with other similar protocols/concepts?
-\item[2:] Is this possible without too much trade-off costs?
-\item[3:] Is this possible without a VMT?
+\item[1:] Is this implementable with compile-time protocols/concepts?
+\item[2:] Is this implementable without three trade-off costs?
+	\subitem Without violating the Runtime cost?
+	\subitem The Verification cost?
+	\subitem The Known-Ahead-Correctness cost?
+\item[3:] Is this implementable without using a VMT?
 \end{itemize}
 }
 
-If 2/3 of those questions fail, 
-you should consider finding another solution to your problem. 
-As it surely has an equivalent without the problematic aspects.
-
-\subsection{The Vettable Pattern, validating containers for Kernel C++.}
-
-The following concept makes sure that the `class T' is truly vettable by the Operating System Kernel.
-Such properties are called `Vettable' in such program.
-
-\begin{lstlisting}
-template <class T, typename OnFallback>
-concept IsVettable = requires(OnFallback fallback) {
-  { Vettable<T>::kValue ? true : fallback() };
-};
-\end{lstlisting}
-
-The vettable structure makes use of template metaprogramming in modern C++ to evaluate whether a container is vettable or not, 
-such containers inherits the `IVettable' structure and are marked final.
-
-\begin{lstlisting}
-struct IVettable {
-  explicit IVettable() = default;
-  virtual ~IVettable() = default;
+If two of the three conditions fail, then the framework fails, and you should consider finding another solution to your problem as it surely has an equivalent without the problematic aspects.
 
-  NE_COPY_DEFAULT(IVettable)
-};
-\end{lstlisting}
+\subsection{Compile-Time Vetting on a Freestanding Domain.}
 
-A vettable system may look as such in a Kernel C++ system.
+The following concept makes sure that the `class T' is vetted by the domain. Such properties are called `Vettable' such program in the domain makes sure that a `Container' is truly deemed fit for a Run-Time or Compile-Time Evaluation Domain. The `IVettable' structure makes use of template meta-programming in C++ to evaluate whether a `Container' shall be vetted, such containers inherit the `IVettable' structure and are marked final. Such system may look like this in a Compile-Time Evaluation Domain:
 
 \begin{lstlisting}
 #define NE_VETTABLE \
@@ -239,19 +196,17 @@ namespace Kernel {
 	};
 	
 	/// @brief Concept version of Vettable.
-	template <typename Type, typename OnFallback>
+	template <class Type, class OnFallback>
 	concept IsVettable = requires(OnFallback fallback) {
 		{ Vettable<Type>::kValue ? TrueResult<Type>::kValue : fallback() };
 	};
 	
-	template <class Type, typename OnFallback>
+	template <class Type, class OnFallback>
 	concept IsNotVettable = requires(OnFallback fallback) {
 		{ !Vettable<Type>::kValue ? TrueResult<Type>::kValue : fallback() };
 	};
 }  // namespace Kernel
-\end{lstlisting}
-
-Source: \href{https://github.com/nekernel-org/nekernel/blob/stable/src/kernel/NeKit/Vettable.h}{https://github.com/nekernel-org/nekernel/blob/stable/src/kernel/NeKit/Vettable.h}
+\end{lstlisting} Source: \href{https://github.com/nekernel-org/nekernel/blob/stable/src/kernel/NeKit/Vettable.h}{https://github.com/nekernel-org/nekernel/blob/stable/src/kernel/NeKit/Vettable.h}
 
 \section{Conclusion}
 {
diff --git a/source/wg02/wg02.tex b/source/wg02/wg02.tex
index bd5a5ce..5dd586d 100644
--- a/source/wg02/wg02.tex
+++ b/source/wg02/wg02.tex
@@ -1,5 +1,5 @@
 % AUTHOR: Amlal El Mahrouss
-% PURPOSE: WG02: The CoreProcessScheduler
+% PURPOSE: he CoreProcessScheduler
 
 \documentclass[11pt, a4paper]{article}
 \usepackage{graphicx}
@@ -8,7 +8,7 @@
 \usepackage{hyperref}
 \usepackage[margin=0.5in,top=1in,bottom=1in]{geometry}
 
-\title{WG02: The CoreProcessScheduler: Governance of Process and Image lifetime.}
+\title{CoreProcessScheduler: Governance of Process and Image lifetime.}
 \author{Amlal El Mahrouss}
 \date{December 2025}
 
@@ -49,11 +49,11 @@
 \end{center}
 
 \abstract
-{The CoreProcessScheduler governs how the scheduling backend and policy of the kernel works, It is the common gateway for schedulers inside NeKernel based systems.}
+{CoreProcessScheduler governs how the scheduling backend and policy of the kernel works, It is the common gateway for schedulers inside NeKernel based systems.}
 
 \section{Introduction}
 
-{The CoreProcessScheduler (now referred as CPS) serves as the foundation between the scheduler backend and kernel.} {It takes care of process life-cycle management, team-based process grouping, and affinity-based CPU based allocation to mention the least.}
+{CoreProcessScheduler (now referred as CPS) serves as the foundation between the scheduler backend and kernel.} {It takes care of process life-cycle management, team-based process grouping, and affinity-based CPU based allocation to mention the least.}
 
 \subsection{The Affinity System}
 
@@ -152,9 +152,9 @@ struct ProcessImage final {
 
 \section{Conclusion}
 
-{The CoreProcessScheduler is a piece of systems design with robust design and useful cases, although useful in desktop/server cases, It may not be suited for every other tasks.}
+{CoreProcessScheduler is a piece of systems design with robust design and useful cases, although useful in desktop/server cases, It may not be suited for every other tasks.}
 
-{And while one scheduler backend (such as the UserProcessScheduler) takes care of user process scheduling and fairness, the CoreProcessScheduler takes care of the foundation for those systems.}
+{And while one scheduler backend (such as the UserProcessScheduler) takes care of user process scheduling and fairness, CoreProcessScheduler takes care of the foundation for those systems.}
 
 \section{References}