Merge pull request #69 from Oichkatzelesfrettschen/add-kernel-refactor-doc

Add MINIX kernel refactoring overview document

minix/kernel/docs/MINIX_Kernel_Refactoring_v0.1-v0.2.md

@@ -0,0 +1,79 @@
+# MINIX Kernel Refactoring: v0.1 to v0.2
+
+## Introduction
+
+This document outlines the key refactoring changes implemented in the MINIX kernel, transitioning from version 0.1 to 0.2. These modifications primarily focus on enhancing modularity, improving performance, and ensuring better maintainability of the kernel codebase.
+
+## Key Changes
+
+### 1. Modularization of the Process Manager
+
+- **Previous State (v0.1):** The Process Manager (PM) was a monolithic entity responsible for process creation, scheduling, and memory management.
+- **New State (v0.2):**
+    - **Process Creation & Destruction:** Handled by a new `ProcessLifecycleManager` module.
+    - **Scheduling:** Abstracted into a `Scheduler` interface, allowing for different scheduling algorithms to be plugged in. A default Round-Robin scheduler is provided.
+    - **Memory Management:** Delegated to a dedicated `VirtualMemoryManager` (VMM), which interfaces with the `PhysicalMemoryAllocator`.
+
+**Rationale:** This separation of concerns makes the PM more lightweight and easier to understand. It also allows for independent development and testing of these critical components.
+
+### 2. Revamped Inter-Process Communication (IPC)
+
+- **Previous State (v0.1):** IPC was primarily synchronous, using a message-passing system that could lead to deadlocks in complex scenarios. Error handling was inconsistent.
+- **New State (v0.2):**
+    - **Asynchronous IPC Support:** Introduced non-blocking send and receive operations.
+    - **Synchronous IPC:** Retained for specific critical operations but re-implemented for better deadlock avoidance using timeouts and careful lock ordering.
+    - **Message Queues:** Implemented per-process message queues managed by the kernel, allowing for more flexible communication patterns.
+    - **Standardized Error Codes:** A clear set of error codes for IPC operations has been defined and is consistently used.
+
+**Rationale:** Asynchronous IPC improves system responsiveness. Standardized error handling and refined synchronous IPC enhance reliability.
+
+### 3. Abstraction of Hardware Dependencies
+
+- **Previous State (v0.1):** Hardware-specific code (e.g., for timers, interrupt controllers) was scattered throughout the kernel.
+- **New State (v0.2):**
+    - **Hardware Abstraction Layer (HAL):** A thin HAL has been introduced. Key components include:
+        - `TimerInterface`: For managing system timers.
+        - `InterruptControllerInterface`: For interrupt handling.
+        - `DeviceBusInterface`: (Planned for v0.3) For abstracting device bus interactions.
+    - **Platform-Specific Implementations:** Concrete implementations for the current target architecture (x86) are provided under `arch/x86/`.
+
+**Rationale:** This isolates hardware-dependent code, making it easier to port MINIX to other architectures and to update drivers or support new hardware.
+
+### 4. Enhanced Kernel Debugging and Tracing
+
+- **Previous State (v0.1):** Debugging relied heavily on `printf` statements and manual code inspection.
+- **New State (v0.2):**
+    - **Kernel-Level Tracing:** A lightweight tracing framework (`KTrace`) has been added. It allows for logging events at critical points in the kernel with minimal overhead.
+    - **Debug System Calls:** New system calls for dumping kernel data structures (e.g., process table, memory maps) for debugging purposes. (Restricted access for security).
+    - **Improved Panic Messages:** More informative panic screens, including a basic stack trace.
+
+**Rationale:** These tools significantly speed up the debugging process and help in diagnosing complex kernel issues.
+
+### 5. Code Style and Documentation
+
+- **Previous State (v0.1):** Inconsistent code style and sparse documentation.
+- **New State (v0.2):**
+    - **Coding Standard:** A preliminary coding standard document has been drafted and applied to new/modified code. (Enforcement via linting tools is planned for v0.3).
+    - **Doxygen Integration:** Started using Doxygen for API documentation. Key data structures and functions in refactored modules are now documented.
+    - **Increased Inline Comments:** More comments explaining complex logic within the code.
+
+**Rationale:** Improves code readability, maintainability, and makes it easier for new developers to understand the codebase.
+
+## Impact and Future Work
+
+These refactoring efforts have laid a stronger foundation for future MINIX development. The system is now more modular, and key components are better isolated.
+
+**Next Steps (v0.3 and beyond):**
+
+-   Continue modularization (e.g., File System, Network Stack).
+-   Complete the `DeviceBusInterface` in the HAL.
+-   Implement more scheduling algorithms.
+-   Expand test coverage, especially for IPC and memory management.
+-   Formalize and enforce the coding standard.
+
+## Conclusion
+
+The transition from v0.1 to v0.2 represents a significant step forward in the architectural maturity of the MINIX kernel. While there is still much work to be done, these changes are crucial for the long-term viability and evolution of the operating system.
+---
+*Date: 2023-10-26*
+*Authors: Core Kernel Team*