# linux2025-homework3

:::danger
說好的進度呢？
:::
## 縮減使用者和核心層級的通訊成本
在這份專案中，我們想要縮減使用者和核心層級的通訊成本，我們要先了解 main.c 以及 xo-user.c 這兩個程式的邏輯與運作方式。

### main.c 的邏輯與功能
1. main.c 屬於 kernel module，負責整個井字棋遊戲核心邏輯與設備驅動的實作，包括棋盤資料的維護、AI 排程、設備檔案操作（如 read/write）、以及用來同步資料存取的 mutex 機制。
2. 最關鍵的是 main.c 負責決定要將哪些資料傳送給 user space。在最初設計中，kernel 端會組合完整的棋盤顯示畫面（含棋子、分隔符、框線等字元），形成 draw_buffer，再將這個大字串傳遞給 user space，這導致每次通訊時都需傳送較大量的冗餘資料。

### xo-user.c 的邏輯與功能
1. xo-user.c 屬於 user space 應用程式，負責從 /dev/kxo 讀取資料並在終端畫面上顯示棋盤狀態，並處理使用者的輸入（如鍵盤控制）。
2. 在初始設計下，xo-user.c 會直接從 kernel 端取得排版完成的棋盤畫面（即 draw_buffer），然後用 printf 輸出到終端，缺乏彈性且接收到的資料量大。
### 溝通成本問題分析

原本的設計下，每次 kernel 傳送資料到 user space，都包含大量冗餘的格式化字元（如分隔符號、框線、換行），使得通訊資料量遠大於實際遊戲狀態所需資訊。

例如對於 4x4 棋盤，原本 draw_buffer 可能高達 64 bytes 或更多，而實際棋盤狀態只需 16 bytes。
### 縮減通訊成本的改進措施
將 kernel 端只負責管理棋盤狀態（table），每一格以一個 byte 表示（0 = 空，1 = O，2 = X）。
資料傳輸時，直接將 table 陣列送到 user space，完全移除格式化字元的傳送。

user space（xo-user.c）收到 table 後，由自己在本地用 draw_board function 動態產生顯示畫面，這樣每次通訊資料量大幅減少，彈性也提高。

## 遇到 Kernel Panic
### Module 移除失敗 ( `rmmod kxo` 無法成功)

在進行 kxo kernel module 改為「只傳送棋盤狀態 table」的優化過程中，遇到了一些典型且少見的 Linux Kernel Module 開發問題：

- **現象描述：**

原編譯後要載入 kxo.ko ，但卻被系統告知以下訊息。

$ user@ting:~/Desktop/kxo$ sudo insmod kxo.ko  
$ insmod: ERROR: could not insert module kxo.ko: Device or resource busy

而在我多次嘗試 `rmmod kxo` 之後，`lsmod` 仍看到顯示為 `Unloading` 狀態。

$ user@ting:~/Desktop/kxo$ lsmod
$ Module                  Size  Used by
$ kxo                    32768  -1

$ user@ting:~/Desktop/kxo$ ls -l /dev/kxo
$ ls: 無法存取 '/dev/kxo': 沒有此一檔案或目錄

$ user@ting:~/Desktop/kxo$ lsmod | grep kxo
$ kxo                    32768  -1

即使多次執行 `sudo rmmod kxo` 或**重開機**，`/proc/modules` 依然顯示 kxo module 存在，且無法重新載入（`insmod` 顯示 "Device or resource busy"）。

**排查步驟：**
1. 使用 `fuser`、`lsof`、`ps aux` 等指令，確保所有 user space 程式（如 xo-user）完全關閉。
2. 嘗試強制 kill 所有相關程序後，再 `rmmod kxo`。
3. 重開機後立即檢查 `/proc/modules`，**仍見 `kxo` 殘留，狀態為 "Unloading"**。

---

### 可能原因推測

- Module exit 釋放資源步驟有誤，reference 計數未歸零（open/release 未正確對應）。
- 內核安全機制（AppArmor、SELinux、rootfs 快照）或混合休眠（Hybrid Sleep）導致核心資料結構殘留。
- Kernel Panic、異常中斷導致模組未能正確卸載。

---

### Kernel Panic 狀況

- 在反覆 insert/remove module 或修改 code、重新編譯測試期間，系統偶爾發生 **Kernel Panic** 或 crash，需強制重啟。
- 疑似因 module exit 流程未完善、reference 計數出錯，導致 kernel 無法正確釋放記憶體資源。

### 解決方式
後來多重開機幾次，就解決了。