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

grawis(吳苙豪)

簡介

  • 國立成功大學 醫學資訊研究所
  • Github: grawis

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

成果發表與貢獻

8分

  • 教材
    • warm-up作業
      • 2026/03/06 : 與老師討論題意修正(信件) 為何 \(x \mod 2^n \equiv x \mod (2^n - 1)\) 僅對 unsigned 或非負整數安全?->為何 \(x \mod 2^n \equiv x \& (2^n - 1)\) 僅對 unsigned 或非負整數安全?
    • 第13周教材:Linux: Scalability 議題
      • 繼續讀取取檔案 -> 繼續讀取檔案
      • 該被被釋放 -> 該被釋放
    • 第13周教材:解析 Linux 共享記憶體機制
      • 程式碼區塊:cpp -> c

作業/隨堂測驗

7分

作業重點回顧:

撰寫作業過程意識到對於基礎的 C 語言有許多未掌握的觀念,如指標、位元運算等。而過去以為自己掌握的演算法、資料結構知識也並不熟悉,因此再去複習各類排序演算法,並藉此延伸到各類演算法行為對於硬體、系統的友善程度與分析,接著學習關於作業系統與 cpu 的新知識。

在第一次作業中,我第一次學習了查閱第一手資料,如 C99 規格書、 linux kernel 原始碼、專案的 commit message 、書本對於觀念和程式碼行為的定義。而在第二次作業後,我開始接觸了在 linux 環境中撰寫測試程式與精準觀察各程式的行為,並學習了 git 版本控制方法。

期末專題

8分

目前已完成貢獻摘要:

研讀過去相關專案貢獻

深入了解虛擬攝影機驅動程式後,發現其涉及的知識領域非常廣大,即使 vcam 還只算是小型模組,但光是 driver 運作流程、 frame buffer 與 不同 buffer 運作行為、控制介面、與 V4L2 API 就有非常多需要理解並進一步完善的部分。而關於基礎影像知識與擴充支援格式等代辦事項也尚未完成。

我目前對專案的整體貢獻聚焦於提升 vcam 對 V4L2 規範的正確性、可測試性與 streaming 行為穩定性,並為後續改良 framebuffer input 與擴充現代影像來源建立基礎。

實際分析並驗證 raw frame 由 /dev/fbX 輸入、經 driver buffer 處理後從 /dev/videoX 以 V4L2 camera 形式輸出的完整流程,並理解 V4L2 format negotiation、videobuf2 buffer queue、streaming 與 frame timing 的運作。過程中完成自動化 V4L2 測試流程、集中 RGB24/YUYV 格式與 bytesperline、sizeimage 計算、修正 frame interval 回報與實際輸出速度不一致問題、避免 buffer 配置後任意變更格式,並補足 capture buffer sequence number 與 tracepoint 觀察。

觀摩其他學員的期末專題:

與授課教師的互動

9分

課堂問答:

  • 3/17 課堂與老師討論關於merge sort程式碼品味與設計策略問題,問答紀錄於3/10問答簡記
  • 3/24 課堂與老師討論關於 quick sort 與 merge sort 在 linked list 上的優劣,問答紀錄於3/17, 3/24問答簡記
  • 5/26 課堂被老師問到 homogeneous 定義的相關問題,問答紀錄於5/26問答簡記

一對一討論:

  • 6/9 和老師一對一詢問關於 vcam 目前的改進方向,老師建議直接提交 issue 與 pr
  • 6/23 和老師一對一詢問關於 vcam 目前的改進方向,老師說關於之前的 pr 未來會再審閱。然後也提及目前 linux kernel 在未來會逐步棄置 frame buffer 的方向,可往替代方案的實作欲完善發展(如改善 dma buffer 的行爲,不再依賴 frame buffer),也在後續補上了這個方向的任務於專題紀錄中。

所見所聞所感

10分

  • 觀察同學們的心得

閱讀了〈因為自動飲料機而延畢的那一年〉後,我看到了書中很理想的目標,卻又參雜了實際的難題、內心的掙扎、取捨,從一年的專案看到了走上工程,甚至是求職、夢想、生活這條道路中遇到的酸甜苦辣。而我認為裡面最有感觸的是「你該學習的不是看到事情要完蛋了就去避免失敗,而是應該學習如何處理與承受失敗,你才能變得比以前更強大。」這段話,不只能對應到職涯,也能對應到許多人生低谷的狀態。既使短期看不到結果,也不能保證方向是對的,在原地的猶豫與徘徊也不會到達成功,只有不斷的撞牆、思考、再前進才會真正的進步。

而在這堂課中,我看到很多非常認真的同學,接觸過的領域各自不同,但許多人的研究精神非常值得我去學習。像是在撰寫第一次作業時,比起看過並複製 AI 的回答,有些同學會去翻閱第一手資料、過去貢獻的 commit message ,甚至設計實驗去驗證行為,並對實驗結果加以分析,提供關於結果的延伸思考等等。我認為這樣深入理解問題並加以思考的方式,才是能夠有效提申自身能力的方式。

而與許多同學小聊後發現,大家其實有很多共同的焦慮。但時刻看見別人的努力、成長,或許也是能有效督促我前進的方式。

  • 觀察老師的心得

老師上課的方式非常熱情,同時也非常嚴厲。修了這堂課後其實也變相的督促我看到了老師大量投入於資訊產業界的貢獻、以及對課程的安排與要求。雖然老師常常對我們破口大罵,但這些確實源自於我知識、技能的不足,或對自我的不誠實。

而對語言的精確度也讓我體會到,量化、精準的溝通,對於自身進步和整體效率是非常必要的。

  • 回顧自身在本課程的投入狀況

會選修這堂課部份源自於對未來的焦慮與自身實力的不足。因此起初對自己的目標是籠統的增強關於 OS 、硬體的基礎知識,並實作對於未來有幫助的專案。

在寫作業的過程中,我理解了大量閱讀並提出反思的重要性,並在2026q1 Homework2 (stdc) 中開始加入了延伸思考,補其自身不足的知識外也學會深入延伸問題,以免止於單純用 AI 回答老師問題的不誠實行為。

而後來投入期末專案,其實一開始非常無從下手,因為對專案本身、相關領域都完全不理解。但透過老師給的建議方向、閱讀原始程式碼、搜尋應用與紀錄,才能從零開始慢慢理解一項新專案,同時從中學會相關工具 (如分析工具 perf、tracepoint) 應用。

最後課堂討論讓我深入研究未曾想過的方向,除了從不同面向並深入研究一單純問題外,老師也不斷提醒我們使用面試標準與態度,以工程思維回答問題。

自我評量 (1 ~ 10)

\(GEOMEAN=(8×7×8×9×10)^{1/5}=8.33881\)

方案 B:\(1+floor(GEOMEAN)=1+8=9\)