# 🚀 NachOS Architecture & MP Implementation: 7-Day Intensive Plan

In the world of Computer Science academia—particularly at universities like **National Yang Ming Chiao Tung University (NYCU)** and **National Tsing Hua University (NTHU)**—**Nachos** (Not Another Completely Heuristic Operating System) is a famous instructional software used to teach the inner workings of an Operating System.

Rather than just reading about how an OS works, students use Nachos to **build one** by writing the actual code for thread management, memory allocation, and file systems.

---

## 1. The Core Concept: A "System within a System"

Nachos is unique because it is a **simulated operating system** that runs as a regular process on top of a host OS (like Linux or Windows).

* **The Machine Layer:** Nachos simulates a **MIPS R2000 CPU**, including its registers, physical memory, and hardware interrupts.
* **The Kernel Layer:** This is where you (the student/developer) write the code. You implement the logic that manages the simulated hardware.
* **User Programs:** You can write small C programs, compile them into MIPS machine code, and "run" them on your Nachos kernel.

---

## 2. What do you actually do in Nachos? (The "Machine Problems")

In a typical OS course, the project is divided into several **Machine Problems (MPs)**. Each one focuses on a pillar of OS design:

| Project | Focus | What you implement |
| --- | --- | --- |
| **MP1: Threads** | **Concurrency** | Thread switching, Semaphores, Locks, and Condition Variables. |
| **MP2: Multiprogramming** | **Virtualization** | System Calls (`Read`, `Write`, `Exit`) and loading multiple programs into memory. |
| **MP3: Scheduling** | **Resource Policy** | Replacing simple Round-Robin with advanced algorithms like Multilevel Feedback Queues. |
| **MP4: File Systems** | **Persistence** | Creating a directory structure and handling file storage on a simulated disk. |

---

## 3. Why is it so "Famous" (and Difficult)?

Nachos is known for being a "rite of passage" for CS students for several reasons:

* **Low-Level Reality:** You have to deal with CPU registers and assembly-level "traps." If your memory management code is off by one byte, the simulated machine crashes.
* **Concurrency Hell:** Debugging race conditions in a multi-threaded kernel is notoriously difficult. You learn very quickly why `Mutexes` and `Semaphores` are essential.
* **The Gap between Theory and Practice:** You move from knowing *what* a System Call is to knowing *exactly* which registers move the data from User Space to Kernel Space.

---

## 4. How it relates to Modern Tech

While Nachos simulates an older MIPS architecture, the concepts are 100% applicable to modern systems:

* **Cybersecurity:** Understanding how `exception.cc` handles system calls is the foundation of understanding **Kernel Exploits** and **Privilege Escalation**.
* **AI Infrastructure:** Efficient thread scheduling (MP3) is exactly what allows high-performance AI clusters to feed data to GPUs without bottlenecks.
* **Systems Programming:** It provides the "low-level intuition" needed to write high-performance code in languages like **Rust** or **C++**.

**Are you currently preparing to set up a Nachos environment for a course, or are you interested in a specific part of the architecture like the Thread Scheduler?**

| Day | Focus Area | Key Learning Objectives & Core Files | Relatable Concepts (AI/Security) |
| --- | --- | --- | --- |
| **Day 1** | **Macro Architecture & Setup** | Understand directory structure, MIPS emulation, and compilation flow. <br><br> 📁 `machine/`, `threads/`, `Makefile` | Hardware-Software Abstraction & Cross-compilation. |
| **Day 2** | **Boot Process & Interrupts** | Trace `main.cc` to see kernel initialization and the event-driven Interrupt Handler. <br><br> 📁 `main.cc`, `interrupt.cc`, `timer.cc` | Event Loops & Asynchronous Processing (Async/Await). |
| **Day 3** | **Thread Management (MP1)** | Deep dive into Thread states (Ready, Running, Blocked) and the `Switch` assembly. <br><br> 📁 `thread.cc`, `scheduler.cc`, `switch.s` | CPU Scheduling & Context Switching (Parallelism). |
| **Day 4** | **Synchronization Primitives** | Mastering Semaphores, Locks, and Condition Variables to prevent Race Conditions. <br><br> 📁 `synch.cc`, `synch.h` | Concurrency Safety (Rust Ownership & Mutexes). |
| **Day 5** | **User vs. Kernel Mode (MP1/2)** | Understanding the "Trap" mechanism and the Exception Handler boundary. <br><br> 📁 `exception.cc`, `syscall.h`, `start.s` | **Security:** Privilege Escalation & System Call Hooking. |
| **Day 6** | **Memory & Address Space (MP2)** | Mapping Virtual Addresses to Physical Addresses using Page Tables. <br><br> 📁 `addrspace.cc`, `machine.h` | **Security:** Buffer Overflows & Memory Isolation. |
| **Day 7** | **Tooling & MP1 Kick-off** | Using GDB for kernel debugging and implementing your first `Console I/O` SysCall. <br><br> 📁 `syscall.h`, `exception.cc` | Low-level Debugging & Kernel Space I/O. |

---

### Detailed Breakdown of Core Components

#### 1. The Machine Layer (`machine/`)

* **MIPS Emulator:** This simulates the physical CPU. You generally **do not** modify this, but you must understand how it interacts with your code.
* **Registers:** Understanding how the `PC` (Program Counter) and `Stack Pointer` work is crucial for MP1.

#### 2. The Kernel Layer (`threads/` & `userprog/`)

* **MP1 (System Calls):** You will modify `exception.cc` to handle requests from User Space.
* **MP2 (Multiprogramming):** You will modify `addrspace.cc` to manage how multiple programs reside in memory simultaneously.
* **MP3 (Scheduling):** You will modify `scheduler.cc` to replace the default Round-Robin with a Multilevel Feedback Queue.

#### 3. The File System Layer (`filesys/`)

* **MP4 (Advanced FS):** You will expand the 4KB limit and implement hierarchical subdirectories, similar to how modern Linux filesystems operate.

---

### 💡 Strategy for Success

* **The "Grep" Method:** Since NachOS is highly interconnected, always search for where a function is defined and where it is called before making changes.
* **Security Mindset:** When implementing MP1 (System Calls), imagine you are an attacker trying to pass a "malicious" pointer from User Space to the Kernel. How would you validate that data?

Would you like me to provide a **sample code snippet for Day 5** (how to handle a System Call in `exception.cc`) to get you started on MP1?