分享到plurk 分享到twitter 分享到facebook

ga13234624(王俐婷)

簡介

2026 Linux 核心設計/實作 自我評量

第一項、成果發表和貢獻

評分: 6

學期內對 lkmpg、vwifi 專案累計 4 件 PR (等待審核中)。 雖然修改項目不多，但我認為我所修改的項目是書籍的實質錯誤，或是會直接影響到專案運行時會不會發生panic，具有相當程度的貢獻，而非只是修改錯字，所以給自己6分。

lkmpg

  • 2026/06/30 — sysprog21/lkmpg 第 10 章< Talking To Device > 提到 “The ioctl number encodes the major device number, the type of the ioctl, the command, and the type of the parameter.” 應為 “The ioctl number encodes the direction of data transfer, the type of the ioctl, the command, and the type of the parameter.”

vwifi 專案

  • 2026/07/02 — vwifi_virtio_mgmt_rx_connect_request() 跟 vwifi_connect_routine() 裡面都用到 sinfo = kmalloc(sizeof(struct station_info), GFP_KERNEL); 並且在後續呼叫 cfg80211_new_sta，因為 cfg80211 是依靠 ->filled 來判斷要讀取哪些欄位，不定期會發生讀到垃圾資料而引發 kernel panic，故修改為 kzalloc 來確保所有欄位初始值為 0。

  • 2026/07/03 — vwifi_get_station 是 non-virtio 與 virtio 模式在查看 station 資訊時都會觸發的函式。在 virtio 模式下，STA 端執行時發生 kernel NULL pointer dereference。原因在於：此函式填 bss_param 時透過 vif->ap->beacon_int 讀取本機 AP 物件，但此僅適用於 non-virtio，在 virtio 模式下 AP 位於另一台 VM，STA 的 vif->ap 為 NULL 是合理的，故未先判斷 vif->ap 是否為 NULL 而直接呼叫mutex_lock_interruptible(&vif->ap->lock)引發了 kernel NULL pointer dereference。

  • 2026/07/04 — vwifi_ndo_start_xmit 在進入時會先判斷是否為 virtio 模式，若是則直接 return vwifi_virtio_tx(vif, skb)，提早離開函式。non-virtio 路徑分別在呼叫的__vwifi_ndo_start_xmit 與函式尾端更新統計數據（tx_packets、tx_bytes、tx_dropped），virtio 路徑完全沒有更新到統計數據，修正方式為在 vwifi_virtio_tx 內補上統計更新。

第二項、作業/隨堂測驗

評分: 7

作業1: 2026q1 Homework1 (warmup)

作業2: 2026q1 Homework2 (stdc)

作業3: 2026q1 Homework3 (basics)

作業4: 選擇第一種路線–即刻投入期末專題(如下)

第三項、期末專題

評分: 10

  • 開發紀錄
  • 專題將 vwifi 擴充為能模擬真實無線環境的版本，讓原本零丟包的虛擬網路，能依照訊號強弱產生封包丟失、延遲。實作上採用雙模組架構，並在封包傳遞路徑上進行攔截，套用一套 RSSI 到丟包率、延遲時間計算的物理模型，同時支援原專案既有的單機與跨 VM 兩種情境，並透過 generic netlink 打造可動態調整物理環境表。
  • 6/23 與老師一對一討論時，老師指出原作法在對外封包上會有問題。我重新探勘了 vwifi 專案原始設計，其定位應是模擬 BSS 內部的成員關係，並不包含對外通訊（因為vwifi_virtio_data_rx() 會檢查封包來源是否存在於 bss_sta_table，而對外封包的來源為 gateway 或外部主機，不可能出現在該表中，因此必然被丟棄）。我推測老師是想告訴我應修改套用物理邏輯層的位置，因為原作法將物理邏輯掛在 host bridge 的 netfilter hook，只能攔截到經過 bridge 轉發的封包。若要確保所有封包都經過物理層，攔截點應移到 guest 端的收發路徑，在封包離開或進入 guest 網卡的當下就套用 RSSI、PER 與延遲模型。據此我重構了整體架構，將物理邏輯自 host 端遷移至 guest 端驅動，並實際驗證對外封包同樣受物理模型影響。

第四項、與授課教師的互動

評分: 5

  • 2026/04/28 下課時間與老師討論專題方向改為 vwifi
  • 2026/06/02 與助教及老師進行模擬面試，並於 6/22 12:28 信件回覆模擬面試相關問題
  • 2026/06/23 與助教進行模擬面試，並於 7/3 15:22 信件回覆模擬面試相關問題
  • 2026/06/24 與老師進行一對一討論 紀錄

第五項、 所見所聞所感

評分: 10

關於〈因為自動飲料機而延畢的那一年〉

我很佩服學長這種為了達成某個目標，哪怕最終的結果對自己未必有實質的好處，仍然願意不計代價地付出所有的時間與精力的人。這讓我想到老師今年去支援的那個”極度忙碌”的專案，有次老師提到他為此甚至連續30多個小時沒有闔眼，而且這個專案實際上也無法給予他多豐厚的酬勞，但他依然選擇投入，老師與學長完全是憑藉著個人的信念與堅持在支撐。

回顧這篇文章，在這種漫長、不斷卡關、反覆修復問題的過程中，人的耐心很容易被消磨殆盡，很容易會產生想放棄的念頭，或是明明已經察覺到了一些潛在的小問題，卻可能會因為疲憊而選擇囫圇吞棗、得過且過地帶過。然而，工程的世界是極度真實且殘酷的，在系統與工程實作上，即便只是一些微小的細節差異或瑕疵，都可能導致整套系統崩潰、讓整台機器無法順利運行。在這個領域裡並沒有所謂的「部份給分」，一切的邏輯與架構都必須是嚴謹且確定的。如同老師時常耳提面命的：「做大事 or nothing」，套用到這個情境其實是完全一樣的道理。以製作這台飲料機為例，你要馬就是徹頭徹尾地完成一台功能完全正確、能順暢運作的機器；只要當中壞了一部分，哪怕只是一個不起眼的微小零件，它都不能再被視為一台「可用」的飲料機。這種不妥協、追求完整與極致的精神，正是我們在面對每一次工程挑戰時，最需要銘記在心的態度。

關於實驗

我在做專題時，第一步就先去讀專案程式碼並動手修改功能，直到要測試時，才開始完整啟動整個專案。但我當時並沒有意識到，原專案在我的電腦上可能因為版本不同等因素，有些功能本來就無法運行，甚至可能原本就存在 Bug。過往的經驗讓我直覺地認為「專案本身一定沒問題」，於是直接進入開發與測試；也因為以前沒有參與過開源專案的開發，從來沒有仔細閱讀 README 並按照其指引去逐步進行實驗。這種「先入為主」的假設，讓我繞了很大的彎。這也是我這次專題實作中，學到最重要也最基本的一件事：在動手修改前，先確保原始專案能成功運行，才是嚴謹的實驗第一步。

關於自身投入的回顧

關於這學期的時間投入，我每週平均大約花 20 ~ 25 小時在這門課上，但遇到期末考前一週，投入時間就會掉到大約 10 小時左右。說實話，我自己心裡很清楚，以我的基礎，即便每週花 25 小時也是完全不夠的。我大多數的時間都花在了 vwifi 這個專案的摸索上，因為我對網路相關的知識幾乎是0，所以大部份時間都是在學習網路的基礎常識，教材的部份大多沒跟上進度，頂多是上課前擠出1~2小時臨時抱佛腳。

自我總評量得分

自我總評量得分為 8 分。

  • GEOMEAN : \(\sqrt[5]{6*7*10*5*10} = 7.318\)
  • 方案 B：\(1+\lfloor 7.318 \rfloor=8\)