Merge pull request #55 from nekernel-org/dev

v0.0.4

6 files changed, 217 insertions, 5 deletions

diff --git a/docs/tex/NOTICE.md b/docs/tex/NOTICE.md
new file mode 100644
index 00000000..5d6eb03f
--- /dev/null
+++ b/docs/tex/NOTICE.md
@@ -0,0 +1,5 @@
+# Notice for LaTeX documents.
+
+## Recommended Tool
+
+`pdflatex` is recommended for this matter, although you are free to use other tools.
diff --git a/docs/tex/binary_mutex.tex b/docs/tex/binary_mutex.tex
new file mode 100644
index 00000000..9b8a1c40
--- /dev/null
+++ b/docs/tex/binary_mutex.tex
@@ -0,0 +1,77 @@
+\documentclass{article}
+\usepackage{graphicx}
+\usepackage{hyperref}
+
+\title{BinaryMutex: Technical Documentation}
+\author{Amlal El Mahrouss}
+\date{\today}
+
+\begin{document}
+
+\maketitle
+
+\section{Abstract}
+
+{The BinaryMutex is a core component of NeKernel (NeKernel/VMKernel) based systems. The pattern excludes other acquirers to own the USER\_PROCESS that is currently being hold. Thus the acquiree is the USER\_PROCESS itself}
+
+\section{Overview}
+
+{The BinaryMutex comes from the need to make sure that no race conditions occurs in kernel code. Most of those race conditions happens in process handling code. Thus the design of the BinaryMutex (which holds a process handle to it)}
+
+\begin{verbatim}
+BinaryMutex mux;
+mux.Lock(process);
+
+// Say we want to interact with the process itself on this thread, 
+we can then make sure that no race condition happens by using:
+constexpr auto kSecondsMax = 5;
+while (mux.WaitForProcess(kSecondsMax));
+
+// finally do our task now.
+
+process.DoFoo();
+\end{verbatim}
+
+\section{Implementation}
+
+The source implementation consists of this simple C++ class:
+
+\begin{verbatim}
+class BinaryMutex final {
+ public:
+  explicit BinaryMutex() = default;
+  ~BinaryMutex()         = default;
+
+ public:
+  bool IsLocked() const;
+  bool Unlock() noexcept;
+
+ public:
+  BOOL WaitForProcess(const UInt32& sec) noexcept;
+
+ public:
+  bool Lock(USER_PROCESS* process);
+  bool LockOrWait(USER_PROCESS* process, TimerInterface* timer);
+
+ public:
+  NE_COPY_DEFAULT(BinaryMutex)
+
+ private:
+  USER_PROCESS* fLockingProcess;
+};
+\end{verbatim}
+
+\section{Conclusion}
+
+{This design pattern is useful for systems that need to make sure that a process isn't tampered by concurrent usages.
+Thus its existence in VMKernel and NeKernel.}
+
+\section{References}
+
+{NeKernel}: \href{https://github.com/nekernel-org/nekernel}{NeKernel}
+
+{VMKernel}: \href{https://snu.systems/specs/vmkernel}{VMKernel}
+
+{BinaryMutex}: \href{https://github.com/nekernel-org/nekernel/blob/dev/dev/kernel/KernelKit/BinaryMutex.h}{BinaryMutex}
+
+\end{document}
diff --git a/docs/tex/core_process_scheduler.tex b/docs/tex/core_process_scheduler.tex
new file mode 100644
index 00000000..b99232bb
--- /dev/null
+++ b/docs/tex/core_process_scheduler.tex
@@ -0,0 +1,130 @@
+\documentclass{article}
+\usepackage{graphicx}
+\usepackage{hyperref}
+
+\title{CoreProcessScheduler: Technical Documentation}
+\author{Amlal El Mahrouss}
+\date{\today}
+
+\begin{document}
+
+\maketitle
+
+\section{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.}
+
+\section{Overview}
+
+{The CoreProcessScheduler (now referred as CPS) serves as the intermediate foundal 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.}
+
+\section{The Affinity System}
+
+{Processes are given CPU time affinity hints using an affinity kind type, these hints help the scheduler run or adjust the current process.}
+
+\subsection{Sample Code \#1}
+
+{The following sample is C++ code.} {The smaller the value, the more critical the process.}
+
+\begin{verbatim}
+enum class AffinityKind : Int32 {
+  kRealTime     = 100,
+  kVeryHigh     = 150,
+  kHigh         = 200,
+  kStandard     = 1000,
+  kLowUsage     = 1500,
+  kVeryLowUsage = 2000,
+};
+\end{verbatim}
+
+\section{The Team System}
+
+{The team system holds process metadata for the backend scheduler to run on. It holds methods and fields for backend specific operations.} {One implementation of such team is the UserProcessTeam object inside NeKernel.}
+
+\subsection{Sample Code \#2}
+
+{The following sample is used to hold team metadata.} {This is part of the NeKernel source tree.}
+
+\begin{verbatim}
+class UserProcessTeam final {
+ public:
+  explicit UserProcessTeam();
+  ~UserProcessTeam() = default;
+
+  NE_COPY_DEFAULT(UserProcessTeam)
+
+  Array<USER_PROCESS, kSchedProcessLimitPerTeam>& AsArray();
+  Ref<USER_PROCESS>&                              AsRef();
+  ProcessID&                                      Id() noexcept;
+
+ public:
+  USER_PROCESS_ARRAY mProcessList;
+  USER_PROCESS_REF   mCurrentProcess;
+  ProcessID          mTeamId{0};
+  ProcessID          mProcessCur{0};
+};
+
+\end{verbatim}
+
+\section{The Process Image System}
+
+{The process image container is a design pattern made to contain process data and metadata, its purpose comes from the lack of mainstream operating systems of such ability to hold metadata.}
+
+{This approach helps separate concerns and give modularity to the system, as the image and process structure are not mixed together.}
+
+\subsection{Sample Code \#3}
+
+{The following sample is a C++ container used to hold process data and metadata.} {This is part of the NeKernel source tree.}
+
+\begin{verbatim}
+struct PROCESS_IMAGE final {
+  explicit PROCESS_IMAGE() = default;
+
+ private:
+  friend USER_PROCESS;
+  friend KERNEL_TASK;
+
+  friend class UserProcessScheduler;
+
+  ImagePtr fCode;
+  ImagePtr fBlob;
+
+ public:
+  Bool HasCode() const { return this->fCode != nullptr; }
+
+  Bool HasImage() const { return this->fBlob != nullptr; }
+
+  ErrorOr<ImagePtr> LeakImage() {
+    if (this->fCode) {
+      return ErrorOr<ImagePtr>{this->fCode};
+    }
+
+    return ErrorOr<ImagePtr>{kErrorInvalidData};
+  }
+
+  ErrorOr<ImagePtr> LeakBlob() {
+    if (this->fBlob) {
+      return ErrorOr<ImagePtr>{this->fBlob};
+    }
+
+    return ErrorOr<ImagePtr>{kErrorInvalidData};
+  }
+};
+
+\end{verbatim}
+
+\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.}
+
+{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.}
+
+\section{References}
+
+{NeKernel}: \href{https://github.com/nekernel-org/nekernel}{NeKernel}
+
+{VMKernel}: \href{https://snu.systems/specs/vmkernel}{VMKernel}
+
+{CoreProcessScheduler C++ Header}: \href{https://github.com/nekernel-org/nekernel/blob/dev/dev/kernel/KernelKit/CoreProcessScheduler.h}{CoreProcessScheduler}
+
+\end{document}
diff --git a/docs/tex/hefs.tex b/docs/tex/hefs.tex
index c947710f..1656e5a9 100644
--- a/docs/tex/hefs.tex
+++ b/docs/tex/hefs.tex
@@ -4,9 +4,9 @@
 \usepackage{longtable}
 \usepackage{listings}
 \geometry{margin=1in}
-\title{HeFS Filesystem Specification (v1.3)}
+\title{HeFS: Hight-throughput extended File System}
 \author{Amlal El Mahrouss}
-\date{2025}
+\date{\today}
 
 \begin{document}
 
diff --git a/docs/tex/mbci.tex b/docs/tex/mini_bus_controller_interface.tex
index 71907376..ba2381b7 100644
--- a/docs/tex/mbci.tex
+++ b/docs/tex/mini_bus_controller_interface.tex
@@ -7,7 +7,7 @@
 \geometry{margin=1in}
 \title{MBCI: Mini Bus Controller Interface Specification}
 \author{Amlal El Mahrouss}
-\date{2025}
+\date{\today}
 
 \begin{document}
 
diff --git a/docs/tex/nefs.tex b/docs/tex/nefs.tex
index 37e43d13..7f2fdd84 100644
--- a/docs/tex/nefs.tex
+++ b/docs/tex/nefs.tex
@@ -21,9 +21,9 @@
   showstringspaces=false
 }
 
-\title{NeFS: New Extended File System Specification}
+\title{NeFS: New Extended File System}
 \author{Amlal El Mahrouss}
-\date{2025}
+\date{\today}
 
 \begin{document}