# 2025q1 Homework5 (assessment)
contributed by < `Jordymalone` >

## 檢視前 6 週學習狀況 (含程式碼審查和課堂討論)

## 記錄閱讀〈因為自動飲料機而延畢的那一年〉的啟發

這幾週參與 Linux 核心設計的課程，在寫作業和看老師提供的材料時，心裡總是浮現一種 **我真的理解了嗎** 的疑惑。許多內容就像是囫圇吞棗，我能照著做，卻無法說清楚**為什麼**要這樣做。當卡住時，我會去參考其他同學的成果。每次看到他們的邏輯清晰、實作細緻，我心中總忍不住想：「他們怎麼那麼猛啊？我怎麼那麼菜？」那種既羨慕又懷疑自己的感覺揮之不去。

從《因為自動飲料機而延畢的那一年》這系列文章中看到了很多啟發和引人省思的名句，也非常佩服筆者在面對重重困難下，卻依然選擇面對的精神。Jserv說:「你該學習的不是看到事情要完蛋了就去避免失敗，而是應該學習如何處理與承受失敗，你才能變得比以前更強大。」這句話讓我重新看待自己卡關的樣子: 不會，是正常的。懷疑自己，是成長的信號。而不放棄理解，才是值得被紀錄的努力。

就像文章裡也說過：「從來就沒有一件事情是容易的。」
即使我現在的作業稱不上是屍體，但套用老師說的 **缺什麼補什麼**，繼續努力。

## 問題紀錄

* [Linux 核心設計: 針對事件驅動的 I/O 模型演化 研讀筆記](https://hackmd.io/@JordyMalone/HJJVKYQkxg)

在探討 I/O models 中，有提到說進入 kernel mode 會分成兩階段 **wait for data** 和 **copy data from kernel to user**，為什麼要分成這兩個階段?

文中也有提到 blocking vs. non-blocking I/O 探討的是 I/O 操作的 **觸發階段** 又是什麼意思? 不董與 **完成階段** 兩者想表達的意思

* [研讀 kecho](https://hackmd.io/@JordyMalone/kecho)

在使用 drop-tcp-socket 時，我們有為它定義以下 callback 函式:

#ifdef HAVE_PROC_OPS
static const struct proc_ops droptcp_proc_fops = {
    .proc_open = droptcp_proc_open,
    .proc_write = droptcp_proc_write,
    .proc_release = droptcp_proc_release,
};
#else
static const struct file_operations droptcp_proc_fops = {
    .owner = THIS_MODULE,
    .open = droptcp_proc_open,
    .write = droptcp_proc_write,
    .release = droptcp_proc_release,
};
#endif

為什麼會需要這個函式? 不能直接用核心提供的 system call 嗎?

* select

> select() 可能回報某個 socket fd 為「可讀」，但接下來的 read 卻仍可能阻塞。例如，資料雖到達，但因檢查碼錯誤被丟棄，導致後續無資料可讀。故建議對不應阻塞的 socket 加上 O_NONBLOCK 旗標

:::info
為什麼會有資料到達，但檢查碼錯誤被丟棄，導致後續無資料可讀的狀況? 不懂..
:::
:::info
我理解 select 的 return value 是 fd 就緒的數量，但她是在什麼情況下會停止輪詢並回傳就緒的 fd (假設今天有就緒的 fd)，是馬上有就緒就回傳嗎?還是會累積到一定的數量?
:::

## 想投入的專案

> [2025q1 Homework1 (ideas)](https://hackmd.io/@JordyMalone/linux2025-ideas)

### 一對一討論

* 2025/05/15
* - [ ] TODO: ktcp / khttpd