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

版本 b332cdb409a585b8627f7f87ac336ae4ae536e10

User/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 或非負整數安全?

作業/隨堂測驗

7分

作業重點回顧:

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

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

期末專題

8分

目前已完成貢獻摘要:

  • 修正 V4L2 capture frame interval 的計算與回報〔PR #50〕
  • 建立自動化 V4L2 測試流程〔PR #51〕
  • 防止 buffer 已配置或使用中時變更影像格式〔PR #53〕
  • 補上 capture buffer 的 sequence number〔PR #55〕

研讀過去相關專案貢獻

深入了解虛擬攝影機驅動程式後,發現其涉及的知識領域非常廣大,即使 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分

自我評量 (1 ~ 10)

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

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