2026年1月20日 星期二
修復 v4l2loopback 0.15.0 的 V4L2 緩衝區佇列問題
## 問題現象
使用 GStreamer v4l2sink 將影像送到 v4l2loopback 虛擬攝影機時出現錯誤：
```
WARN v4l2bufferpool: buffer X was not queued, this indicates a driver bug
```
經過分析發現是 v4l2loopback 0.15.0 違反 V4L2 規格所致。
## V4L2 緩衝區佇列規格
V4L2 規格定義的緩衝區使用流程：
1. **VIDIOC_REQBUFS** - 配置緩衝區
2. **VIDIOC_QBUF** - 將緩衝區排入驅動程式佇列
3. **VIDIOC_DQBUF** - 從驅動程式佇列取出緩衝區
核心規則：DQBUF 只能回傳先前透過 QBUF 排入的緩衝區。
正確流程：`QBUF → (處理) → DQBUF → QBUF → (處理) → DQBUF ...`
v4l2loopback 0.15.0 的錯誤流程：`(預填充) → DQBUF → (自動循環) → DQBUF → (自動循環) → DQBUF ...`
錯誤點：完全不需要 QBUF，DQBUF 永遠有可用緩衝區。
## v4l2loopback 0.15.0 的問題
### prepare_buffer_queue() 預先填充佇列
```c
/* 原始碼 */
for (pos = 0; pos < count; ++pos) {
bufd = &dev->buffers[pos];
if (list_empty(&bufd->list_head))
list_add_tail(&bufd->list_head, &dev->outbufs_list);
}
```
問題：所有緩衝區在配置後立即被加入輸出佇列，沒有經過 QBUF。
### vidioc_dqbuf() 循環使用緩衝區
```c
/* 原始碼 */
bufd = list_first_entry_or_null(&dev->outbufs_list, ...);
if (bufd)
list_move_tail(&bufd->list_head, &dev->outbufs_list);
```
問題：使用 `list_move_tail()` 將緩衝區移到佇列尾端，形成循環。
### 違反規格的行為
1. 緩衝區未經 QBUF 就出現在輸出佇列
2. DQBUF 回傳從未排入的緩衝區
3. 緩衝區自動循環使用
實際流程：`DQBUF → DQBUF → DQBUF ...` (完全不需要 QBUF)
### GStreamer 的檢查
GStreamer v4l2bufferpool 會追蹤已排入的緩衝區。收到未排入的緩衝區時報錯：
```
WARN v4l2bufferpool: buffer X was not queued, this indicates a driver bug
```
這是正確的行為，因為驅動程式確實違反了規格。
## 修復方法
### 修改 prepare_buffer_queue()
清空輸出佇列，不要預先填充：
```c
/* 清空輸出佇列 */
list_for_each_entry_safe(bufd, n, &dev->outbufs_list, list_head) {
list_del_init(&bufd->list_head);
}
/* 重設緩衝區狀態 */
for (pos = 0; pos < count; ++pos) {
bufd = &dev->buffers[pos];
unset_flags(bufd->buffer.flags);
dev->bufpos2index[pos % count] = bufd->buffer.index;
}
```
### 修改 vidioc_dqbuf()
移除緩衝區，不要循環使用：
```c
bufd = list_first_entry_or_null(&dev->outbufs_list, ...);
if (bufd)
list_del_init(&bufd->list_head); /* 移除，不循環 */
```
### 修復後的行為
- 輸出佇列初始為空
- 緩衝區只在透過 QBUF 排入時才進入輸出佇列
- DQBUF 移除緩衝區，不循環使用
- 符合 V4L2 規格要求
## 測試驗證
修復前：
```bash
gst-launch-1.0 icamerasrc ! v4l2sink device=/dev/video0
# ERROR: buffer X was not queued, this indicates a driver bug
```
修復後：
```bash
gst-launch-1.0 icamerasrc ! v4l2sink device=/dev/video0
# 正常運作，無錯誤訊息
# Firefox/Chrome 可正常使用虛擬攝影機
```
## 技術細節
### 為什麼原設計會預先填充？
v4l2loopback 作為虛擬裝置，可能想簡化緩衝區管理，確保永遠有可用緩衝區。但這違反了 V4L2 規格，與嚴格遵循規格的程式（如 GStreamer）不相容。
### list_del_init vs list_move_tail
- `list_del_init()`: 明確表示「緩衝區不在佇列中」
- `list_move_tail()`: 暗示「移到另一個位置」，語義模糊
使用 `list_del_init()` 讓緩衝區狀態更清楚。
### 多執行緒考量
正確的緩衝區狀態追蹤在多執行緒環境下很重要，可避免競爭條件。
## 參考資料
- V4L2 Buffer: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/buffer.html
- VIDIOC_QBUF/DQBUF: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/vidioc-qbuf.html
- V4L2 Streaming I/O: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/io.html
- GStreamer v4l2bufferpool: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/main/subprojects/gst-plugins-good/sys/v4l2/gstv4l2bufferpool.c
## 上游貢獻
修補程式已提交至上游：https://github.com/v4l2loopback/v4l2loopback/pull/656
## 結論
V4L2 緩衝區管理規格的核心原則：
1. 明確的狀態轉換：QBUF → DQBUF
2. 應用程式控制：由應用程式決定何時提供緩衝區
3. 可預測行為：嚴格遵循規格
當應用程式報告 "driver bug" 時，通常確實是驅動程式的問題。
2016年9月5日 星期一
Linux 系統上面的 NVIDIA 圖形顯示的私有驅動程式
NVIDIA 官方網站上面有提供驅動程式的下載，只是不曉得是否有支援我們正在使用的顯示晶片。
最直接的方式是將驅動程式下載後解開來看裡面的 README.txt 的內容，例如目前最新的 Beta 版本 NVIDIA-Linux-x86_64-370.23.run，下載後可執行以下指令來解開它。
$ bash NVIDIA-Linux-x86_64-370.23.run -x
然後就可以去查看 NVIDIA-Linux-x86_64-370.23 目錄底下的 README.txt 檔案。
然後直接跳轉到 Appendix A. Supported NVIDIA GPU Products 的地方，就可以看到許多的 Device PCI ID，這時候再去對一下自己系統上面的 lspci -vnn 的輸出上面的 NVIDIA 顯示都是 10de 開頭的。
Appendix A. Supported NVIDIA GPU Products
______________________________________________________________________________
...
A1. NVIDIA GEFORCE GPUS
NVIDIA GPU product Device PCI ID* VDPAU features
---------------------------------- --------------- ---------------
GeForce GTX 480 06C0 C
...
GeForce GT 620M 0DE9 1025 0692 C
...
...
像是 06C0 對應到 [10de:06c0] 只要對一組 PCI ID 就好了，而 0DE9 1025 0692 則是對應到 [10de:0de9] 然後還要檢查 Subsystem ID 是不是 [1025:0692]，類似下面的輸出（假造的）。
00:02.0 VGA compatible controller [0300]: NVIDIA GeForce GT 620M [10de:0de9] (rev 00) (prog-if 00 [VGA controller]) Subsystem: Foo bar system [1025:0692]
如果系統上面的 Device PCI ID 跟 Subsystem PCI ID 有跟 README.txt 裡面的符合就表示這個驅動程式應該有支援，如果沒有出現在 README.txt 裡面的話，就是沒有支援。
而 Ubuntu 上面的 NVIDIA 私有驅動也是透過同樣的 README.txt 轉換成 dh-modaliases 使用的格式，讓使用者可以透過 ubuntu-drivers 來自動找到合適的驅動程式。
$ apt-cache show nvidia-361 Package: nvidia-361 Priority: optional Section: restricted/misc Installed-Size: 292039 Maintainer: Ubuntu Core Developers <...> Architecture: amd64 Source: nvidia-graphics-drivers-361 ... Description: NVIDIA binary driver - version 361.42 Description-md5: 2f2445ec5e04329593078984a32bc2ae Modaliases: nvidia_361(pci:v000010DEd000006C0sv*sd*bc03sc*i*,...
2009年6月17日 星期三
FreedomHEC Taipei 2009 - Day 2
第一個議程由 CIH 介紹 Linux Kernel Module 的逆向工程
背景故事是說老闆要他 porting 一個 WLAN driver 可是沒有 datasheet 可以參考
剛好那個 WLAN driver 少了四個整數值的 header file
問題是他也不熟 ARM 的組合語言 於是他就憑藉著 GCC 的 Cross Compiler 還有中斷向量表的基本觀念
在程式碼裡面填入 asm("nop"); 指令識別透過 arm-linux-gcc -S 的指令轉譯成 ARM 的組合語言
利用這樣的技巧找出無限迴圈跟函式執行進入點 ARM 的組合語言
然後將記憶體整個 dump 出來分析 (通常網通裝置的 Linux 系統所使用的記憶體不會太大, 一般在 64M 以下)
還有透過將無限迴圈放到中斷向量表裡面一步一步抽絲剝繭地將四個重要的整數值找出來
第二個議程由 Peter Stuge 來介紹 CoreBoot (前身為 LinuxBIOS)
CoreBoot 最早叫做 LinuxBIOS 就名稱上看來就是用來啟動 Linux 的 BIOS
後來因為它也可以載入 Linux 以外的 Payload (Payload 不負責任譯為"某種會花費硬體資源的載體")
就連 GRUB 也算是一種 Payload 更多的 Payloads 在 http://www.coreboot.org/Payloads 可以看到
這東西的概念簡單說就是 GPL 授權的 BIOS 讓從事 BIOS 開發不用再從頭寫起
目前已經支援某些特定主機板的清單可以在 http://www.coreboot.org/Supported_Motherboards 上面看到
另外有趣的小東西是 BSD 授權的 Libpayload 讓你寫出自己的載體讓 CoreBoot 來載入
第三個議程由 Jon Corbet 來介紹 Kernel Community
介紹整個 Linux Kernel 開發的合作模式
就是 Linus Torvalds 本人並不會直接收別人給他的 Patch
所以別天真的以為可以把自己的 Patch 直接送給 Linus Torvalds
Linus Torvalds 只會從幾位重要的 Developer 那邊接收 Changesets
Linux Kernel 是個相當活耀開發的計畫有上千個活躍的開發者
Linus Torvalds 不可能一個人去處理所有的程式碼合併跟衝突解決
當然這所有的工作都是靠優秀的 Git 分散式版本控制系統還有優秀的同伴們協力達成的 (他們演講時沒怎麼提到 Git)
簡單說就是 Linus Torvalds 會收一小群人給的 Changesets 然後那一小群人又會從其他人那邊收 Changesets 或是 Patch
最後在 Merge Window 的時候全部再匯集在一起然後釋出 rc1
然後就是 Stabilization 所以不會再接受任何新功能
經過好幾次的 rcN release 覺得差不多了就正式 release 然後再繼續下一個 cycle
一個 cycle 大約 8~12 個星期
一個 stable 的 release 只會維護半年的安全性跟嚴重錯誤修正
另外就是有兩個特別的開發樹
一個是 linux-next 提前為下一個 mainline cycle 的 patches 整合做測試
一個是 -mm 以 linux-next 為基底收集更多雜七雜八的 patches 來做測試
最後子系統的維護者們其實才是把關者也就是所有的 patches 應該要直接送給這些維護者們去做 merge 才對
但是這些子系統的維護者們也並不是擁有絕對的權利
也就是說凡是都還是有商量的餘地
第四個議程 Greg KH 介紹 Linux Driver Project
總之 Greg KH 說把你的 Linux Driver 送交到這個計畫吧
這邊會收任何 Kernel Module 的 patches
也歡迎硬體廠商提供測試機器協助他們測試驅動程式是否正常
就算硬體都還沒有生出來也沒關係
反正早點送 patches 早點 Code Review
不用等到都做完再去送 patches
或者是你的硬體需要有人寫 Linux Driver 嗎
這邊有太多閒著沒事想要寫 Linux Driver 的人
要簽署 NDA 文件也是可以接受的
Linux Driver Project 的網址在 http://www.linuxdriverproject.org/
台灣的硬體廠商們還不快點行動嗎~ :P
第五個議題 Harald Welte 介紹 GPL Compliance
簡單講就是你有用 Linux System 做硬體嗎？
那麼你最好依照相關的規定把該放出來的 Source Code 放出來
人在做 天在看 還有我們一群擅長逆向工程的高手在看 前面 CIH 就介紹過一些方法了
不然我們找到證據就會跑去告你喔~ :O
你看我們有很多合作的模範廠商
咦~ 有些被我們告過囉~ 不過沒關係~ 後來大家都和好了~ :P
另外就是提醒程式開發者們
如果程式碼裡面有一些錯字沒關係就留在那邊
那些錯字可以方便以後我們逆向工程找證據出來
最後就是所有的講者上台接受大家問問題~
照片可以在 http://www.flickr.com/photos/acelan/3617233294/
然後就聽到大長輩田欣先生在用英文一些問題
還有這個活動籌辦人之一的 Scott Tsai 提供即時的中英雙向翻譯
Scott 自己本身也問了一些問題
在聽眾們沒有什麼問題的情況下
講者反問了聽眾們一些問題
然後又聽見田欣先生在用英文回答
還有幾位強者 Matt Hsu, Thinker, ... 也是用英文在問問題回答講者的問題
這兩天的活動於是就圓滿的結束了~
中午提供的便當還蠻好吃的~ :P
第一天中午的便當主菜有雞腿副菜有豬肉
第二天中午的便當主菜有魚副菜也有豬肉
中午吃飯的時候旁邊的窗簾被整個拉開
可以從 14 樓的窗戶看到一排山還有內湖的摩天輪
景色相當好看~ :D
以上是筆者參加過後得心得分享
因為過了一星期才憑回憶攥寫
內容不一定與當天實際情狀相符
背景故事是說老闆要他 porting 一個 WLAN driver 可是沒有 datasheet 可以參考
剛好那個 WLAN driver 少了四個整數值的 header file
問題是他也不熟 ARM 的組合語言 於是他就憑藉著 GCC 的 Cross Compiler 還有中斷向量表的基本觀念
在程式碼裡面填入 asm("nop"); 指令識別透過 arm-linux-gcc -S 的指令轉譯成 ARM 的組合語言
利用這樣的技巧找出無限迴圈跟函式執行進入點 ARM 的組合語言
然後將記憶體整個 dump 出來分析 (通常網通裝置的 Linux 系統所使用的記憶體不會太大, 一般在 64M 以下)
還有透過將無限迴圈放到中斷向量表裡面一步一步抽絲剝繭地將四個重要的整數值找出來
第二個議程由 Peter Stuge 來介紹 CoreBoot (前身為 LinuxBIOS)
CoreBoot 最早叫做 LinuxBIOS 就名稱上看來就是用來啟動 Linux 的 BIOS
後來因為它也可以載入 Linux 以外的 Payload (Payload 不負責任譯為"某種會花費硬體資源的載體")
就連 GRUB 也算是一種 Payload 更多的 Payloads 在 http://www.coreboot.org/Payloads 可以看到
這東西的概念簡單說就是 GPL 授權的 BIOS 讓從事 BIOS 開發不用再從頭寫起
目前已經支援某些特定主機板的清單可以在 http://www.coreboot.org/Supported_Motherboards 上面看到
另外有趣的小東西是 BSD 授權的 Libpayload 讓你寫出自己的載體讓 CoreBoot 來載入
第三個議程由 Jon Corbet 來介紹 Kernel Community
介紹整個 Linux Kernel 開發的合作模式
就是 Linus Torvalds 本人並不會直接收別人給他的 Patch
所以別天真的以為可以把自己的 Patch 直接送給 Linus Torvalds
Linus Torvalds 只會從幾位重要的 Developer 那邊接收 Changesets
Linux Kernel 是個相當活耀開發的計畫有上千個活躍的開發者
Linus Torvalds 不可能一個人去處理所有的程式碼合併跟衝突解決
當然這所有的工作都是靠優秀的 Git 分散式版本控制系統還有優秀的同伴們協力達成的 (他們演講時沒怎麼提到 Git)
簡單說就是 Linus Torvalds 會收一小群人給的 Changesets 然後那一小群人又會從其他人那邊收 Changesets 或是 Patch
最後在 Merge Window 的時候全部再匯集在一起然後釋出 rc1
然後就是 Stabilization 所以不會再接受任何新功能
經過好幾次的 rcN release 覺得差不多了就正式 release 然後再繼續下一個 cycle
一個 cycle 大約 8~12 個星期
一個 stable 的 release 只會維護半年的安全性跟嚴重錯誤修正
另外就是有兩個特別的開發樹
一個是 linux-next 提前為下一個 mainline cycle 的 patches 整合做測試
一個是 -mm 以 linux-next 為基底收集更多雜七雜八的 patches 來做測試
最後子系統的維護者們其實才是把關者也就是所有的 patches 應該要直接送給這些維護者們去做 merge 才對
但是這些子系統的維護者們也並不是擁有絕對的權利
也就是說凡是都還是有商量的餘地
第四個議程 Greg KH 介紹 Linux Driver Project
總之 Greg KH 說把你的 Linux Driver 送交到這個計畫吧
這邊會收任何 Kernel Module 的 patches
也歡迎硬體廠商提供測試機器協助他們測試驅動程式是否正常
就算硬體都還沒有生出來也沒關係
反正早點送 patches 早點 Code Review
不用等到都做完再去送 patches
或者是你的硬體需要有人寫 Linux Driver 嗎
這邊有太多閒著沒事想要寫 Linux Driver 的人
要簽署 NDA 文件也是可以接受的
Linux Driver Project 的網址在 http://www.linuxdriverproject.org/
台灣的硬體廠商們還不快點行動嗎~ :P
第五個議題 Harald Welte 介紹 GPL Compliance
簡單講就是你有用 Linux System 做硬體嗎？
那麼你最好依照相關的規定把該放出來的 Source Code 放出來
人在做 天在看 還有我們一群擅長逆向工程的高手在看 前面 CIH 就介紹過一些方法了
不然我們找到證據就會跑去告你喔~ :O
你看我們有很多合作的模範廠商
咦~ 有些被我們告過囉~ 不過沒關係~ 後來大家都和好了~ :P
另外就是提醒程式開發者們
如果程式碼裡面有一些錯字沒關係就留在那邊
那些錯字可以方便以後我們逆向工程找證據出來
最後就是所有的講者上台接受大家問問題~
照片可以在 http://www.flickr.com/photos/acelan/3617233294/
然後就聽到大長輩田欣先生在用英文一些問題
還有這個活動籌辦人之一的 Scott Tsai 提供即時的中英雙向翻譯
Scott 自己本身也問了一些問題
在聽眾們沒有什麼問題的情況下
講者反問了聽眾們一些問題
然後又聽見田欣先生在用英文回答
還有幾位強者 Matt Hsu, Thinker, ... 也是用英文在問問題回答講者的問題
這兩天的活動於是就圓滿的結束了~
中午提供的便當還蠻好吃的~ :P
第一天中午的便當主菜有雞腿副菜有豬肉
第二天中午的便當主菜有魚副菜也有豬肉
中午吃飯的時候旁邊的窗簾被整個拉開
可以從 14 樓的窗戶看到一排山還有內湖的摩天輪
景色相當好看~ :D
以上是筆者參加過後得心得分享
因為過了一星期才憑回憶攥寫
內容不一定與當天實際情狀相符
FreedomHEC Taipei 2009 - Day 1
FreedomHEC 的全名是 Freedom Hardware Engineer Conference
中文應該是翻成『自由硬體工程師研討會』
如果沒弄錯今年是第二次舉辦 (因為第一次我沒跟到... >_<)
這次的活動總共兩天的議程
網址 http://freedomhectaipei.pbworks.com/
FreedomHEC Taipei 2009 - Day 1
第一個議程由 Jon Corbet 介紹 2.6.X 每個正式 Release 版本改進了哪些功能
只是單純地介紹歷史帶過... 不過內容好像在跟 Jon Corbet 在 LWN 上面寫的都一樣
也就是說他的投影片就是那些每次 Linux Kernel Release 時都會在 LWN 上面寫的東西是一樣的
第二個議程由 Jim Huang (jserv) & Matt Hsu 講 Qi (气) 這個簡單化的 bootloader
內容主要是在講 Qi 將 bootloader 的功能盡量地簡化把複雜的功能交給一個客製化的 Linux Kernel 來處理
也就是說 Qi 只專注在載入一個客製化的 Linux Kernel 然後再讓客製化的 Linux Kernel 透過 kexec() 來載入另一個 Linux Kernel
好處是那個客製化的 Linux Kernel 可以透過許多原本就已經支援的網路裝置
將另一個放在 TFTP 或是 NFS 上面的 Linux Kernel 載入記憶體中並且執行起來
或是載入執行在 SD / USB 等裝置上面的 Linux Kernel
在一些 Flash 儲存裝置的 Linux Driver 還沒有 Ready 前就可以做先期的開發工作
第三個議程是由 Fred Chien 介紹 Linux 快速開機的方法
像是分析啟動時的開機時間統計然後調整 /etc/init.d 裡面 script 執行的順序
或是利用一些 readahead 之類的工具事先將需要載入系統的函式庫提先載入
還有把不需要的 Linux Kernel Module 拿掉 把需要的 Linux Kernel Module build-in
改 XWindow 的滑鼠驅動程式 ... (這個筆者兩三年前在前公司也弄過, 還有改 VGA Driver)
另外就是利用休眠的功能將記憶體的資料寫到儲存裝置上
下次開機再將那些資料讀回記憶體之中
還有關閉掉一些在 BIOS 裡面不需要啟動的硬體功能減少 BIOS 啟動時間
或是將一些系統服務的啟動放在 XWindow 起來之後再去做
第四個議題是由在 VIA 服務的 Joseph Chan 介紹 VIA 是怎麼將他們公司的硬體驅動程式提交進 Linux Kernel mainline 裡面
有兩點需要注意的
第一點 Coding Style
Linux Kernel 有著慣用的 Coding Style 沒理由 Linux Kernel 的 Source Code 要去 follow 某間公司的 Coding Style
所以想要提交程式碼進去 Linux Kernel 的廠商首先就是要調整 Coding Style 去適應 Linux Kernel
而不是自己關上門來硬幹等到最後提交的時候才發現 Coding Style 要大修改
第二點 Mailing List 上面的 Review Feedback
並不是將程式碼提交出去就算是交差了事了，更重要的是要聆聽開發者的意見還有耐心等待
並不是開發者都閒閒沒事做在那邊等著別人送 Patch 給他 Review，所以要等到開發者有時間才會去看你的程式碼去給 Review Feedback
還有要注意的是收到回應後應該要馬上給對方回應儘快去修改程式碼再去做提交
而 Joseph Chan 正是將 VIA 所遭遇到的慘痛經驗分享給與會者
第五個議題是由 Greg KH 帶著大家一步一步去寫出 Linux Kernel 上面的 USB 溫度計的 Kernel Module
Greg KH 與前面的講者 Jon Corbet 剛好都是 Linux 驅動程式這本書籍的作者
所以其實 Greg KH 介紹的東西在看過這本書之後，其實很快就可以上手了
主要的重點在於 Greg KH 介紹了 USB Subsystem 的基本架構
介紹 Interface/Config 跟 IN/OUT/Endpoint{Interrupt,Bulk,Isolate} 這些觀念
然後就是一個範例一個範例地帶大家一步一步地寫出 USB 溫度計的驅動程式
中文應該是翻成『自由硬體工程師研討會』
如果沒弄錯今年是第二次舉辦 (因為第一次我沒跟到... >_<)
這次的活動總共兩天的議程
網址 http://freedomhectaipei.pbworks.com/
FreedomHEC Taipei 2009 - Day 1
第一個議程由 Jon Corbet 介紹 2.6.X 每個正式 Release 版本改進了哪些功能
只是單純地介紹歷史帶過... 不過內容好像在跟 Jon Corbet 在 LWN 上面寫的都一樣
也就是說他的投影片就是那些每次 Linux Kernel Release 時都會在 LWN 上面寫的東西是一樣的
第二個議程由 Jim Huang (jserv) & Matt Hsu 講 Qi (气) 這個簡單化的 bootloader
內容主要是在講 Qi 將 bootloader 的功能盡量地簡化把複雜的功能交給一個客製化的 Linux Kernel 來處理
也就是說 Qi 只專注在載入一個客製化的 Linux Kernel 然後再讓客製化的 Linux Kernel 透過 kexec() 來載入另一個 Linux Kernel
好處是那個客製化的 Linux Kernel 可以透過許多原本就已經支援的網路裝置
將另一個放在 TFTP 或是 NFS 上面的 Linux Kernel 載入記憶體中並且執行起來
或是載入執行在 SD / USB 等裝置上面的 Linux Kernel
在一些 Flash 儲存裝置的 Linux Driver 還沒有 Ready 前就可以做先期的開發工作
第三個議程是由 Fred Chien 介紹 Linux 快速開機的方法
像是分析啟動時的開機時間統計然後調整 /etc/init.d 裡面 script 執行的順序
或是利用一些 readahead 之類的工具事先將需要載入系統的函式庫提先載入
還有把不需要的 Linux Kernel Module 拿掉 把需要的 Linux Kernel Module build-in
改 XWindow 的滑鼠驅動程式 ... (這個筆者兩三年前在前公司也弄過, 還有改 VGA Driver)
另外就是利用休眠的功能將記憶體的資料寫到儲存裝置上
下次開機再將那些資料讀回記憶體之中
還有關閉掉一些在 BIOS 裡面不需要啟動的硬體功能減少 BIOS 啟動時間
或是將一些系統服務的啟動放在 XWindow 起來之後再去做
第四個議題是由在 VIA 服務的 Joseph Chan 介紹 VIA 是怎麼將他們公司的硬體驅動程式提交進 Linux Kernel mainline 裡面
有兩點需要注意的
第一點 Coding Style
Linux Kernel 有著慣用的 Coding Style 沒理由 Linux Kernel 的 Source Code 要去 follow 某間公司的 Coding Style
所以想要提交程式碼進去 Linux Kernel 的廠商首先就是要調整 Coding Style 去適應 Linux Kernel
而不是自己關上門來硬幹等到最後提交的時候才發現 Coding Style 要大修改
第二點 Mailing List 上面的 Review Feedback
並不是將程式碼提交出去就算是交差了事了，更重要的是要聆聽開發者的意見還有耐心等待
並不是開發者都閒閒沒事做在那邊等著別人送 Patch 給他 Review，所以要等到開發者有時間才會去看你的程式碼去給 Review Feedback
還有要注意的是收到回應後應該要馬上給對方回應儘快去修改程式碼再去做提交
而 Joseph Chan 正是將 VIA 所遭遇到的慘痛經驗分享給與會者
第五個議題是由 Greg KH 帶著大家一步一步去寫出 Linux Kernel 上面的 USB 溫度計的 Kernel Module
Greg KH 與前面的講者 Jon Corbet 剛好都是 Linux 驅動程式這本書籍的作者
所以其實 Greg KH 介紹的東西在看過這本書之後，其實很快就可以上手了
主要的重點在於 Greg KH 介紹了 USB Subsystem 的基本架構
介紹 Interface/Config 跟 IN/OUT/Endpoint{Interrupt,Bulk,Isolate} 這些觀念
然後就是一個範例一個範例地帶大家一步一步地寫出 USB 溫度計的驅動程式
訂閱：
文章 (Atom)