feat: tex: new revision of tex specs.

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

3 files changed, 21 insertions, 10 deletions

diff --git a/docs/tex/binary_mutex.tex b/docs/tex/binary_mutex.tex
index cc5a7d3c..564d322a 100644
--- a/docs/tex/binary_mutex.tex
+++ b/docs/tex/binary_mutex.tex
@@ -13,7 +13,9 @@
 
 {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{Use Case \#1: Process lock for atomic data retrival}
+\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;
@@ -22,14 +24,16 @@ 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;
-mux.WaitForProcess(kSecondsMax);
+while (mux.WaitForProcess(kSecondsMax));
+
+// finally do our task now.
 
 process.DoFoo();
 \end{verbatim}
 
 \section{Implementation}
 
-The source implementation consists of:
+The source implementation consists of this simple C++ class:
 
 \begin{verbatim}
 class BinaryMutex final {
@@ -58,6 +62,15 @@ class BinaryMutex final {
 
 \section{Conclusion}
 
-This 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.
+{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/coreprocessscheduler.tex b/docs/tex/core_process_scheduler.tex
index dd3594b1..b99232bb 100644
--- a/docs/tex/coreprocessscheduler.tex
+++ b/docs/tex/core_process_scheduler.tex
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{graphicx} % Required for inserting images
+\usepackage{graphicx}
 \usepackage{hyperref}
 
 \title{CoreProcessScheduler: Technical Documentation}
@@ -70,8 +70,6 @@ class UserProcessTeam final {
 
 {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.}
 
-\newline
-
 {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}
@@ -123,10 +121,10 @@ struct PROCESS_IMAGE final {
 
 \section{References}
 
-{Here are the reference mentioned on this paper:}
-
 {NeKernel}: \href{https://github.com/nekernel-org/nekernel}{NeKernel}
 
-{CoreProcessScheduler}: \href{https://github.com/nekernel-org/nekernel/blob/dev/dev/kernel/KernelKit/CoreProcessScheduler.h}{CoreProcessScheduler}
+{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/mbci.tex b/docs/tex/mini_bus_controller_interface.tex
index 71907376..71907376 100644
--- a/docs/tex/mbci.tex
+++ b/docs/tex/mini_bus_controller_interface.tex