1. 媒體子系統概況

1.1. 概述

媒體子系統涵蓋對各種裝置的支援：流捕獲、模擬和數字電視流、相機、遙控器、HDMI CEC 和媒體管道控制。

主要涵蓋以下目錄的內容

  • drivers/media

  • drivers/staging/media

  • Documentation/admin-guide/media

  • Documentation/driver-api/media

  • Documentation/userspace-api/media

  • Documentation/devicetree/bindings/media/[1]

  • include/media

媒體使用者空間和核心 API 都已記錄在案，並且文件必須與 API 更改保持同步。這意味著所有為子系統新增新功能的補丁也必須更改相應的 API 檔案。

由於媒體子系統的大小和範圍廣泛，媒體的維護模式是擁有對子系統的特定方面具有廣泛知識的子維護者。子維護者的任務是審查補丁，如果補丁遵循子系統規則並正確使用媒體核心和使用者空間 API，則向用戶提供反饋。

媒體子系統的補丁必須以純文字電子郵件的形式傳送到媒體郵件列表 linux-media@vger.kernel.org。帶有 HTML 的電子郵件將被郵件伺服器自動拒絕。也可以抄送子維護者。

媒體的工作流程主要基於 Patchwork，這意味著，一旦提交補丁，電子郵件將首先被郵件列表伺服器接受，過一段時間後，它應該出現在

如果在幾分鐘後沒有自動出現在那裡，那麼您的提交可能出了問題。請檢查電子郵件是否為純文字[2]，並且您的電子郵件客戶端在抱怨或再次提交之前沒有篡改空格。

您可以透過檢視以下內容來檢查郵件列表伺服器是否接受了您的補丁

1.1.1. 媒體維護者

在媒體子系統中，我們有一群資深開發人員負責在驅動程式中進行程式碼審查（也稱為子維護者），另一位資深開發人員負責整個子系統。對於核心更改，如果可能，多個媒體維護者會進行審查。

在子系統的特定領域工作的媒體維護者有

子系統維護者是

Mauro Carvalho Chehab <mchehab@kernel.org>

媒體維護者可以根據需要將補丁委派給其他媒體維護者。在這種情況下，checkpatch 的 delegate 欄位指示當前負責審查補丁的人員。

1.2. 提交清單附錄

更改 Open Firmware/裝置樹繫結的補丁必須由裝置樹維護者審查。因此，當透過 devicetree@vger.kernel.org 郵件列表提交這些補丁時，應該抄送 DT 維護者。

在 https://git.linuxtv.org/v4l-utils.git/ 有一套合規性工具，應該使用這些工具來檢查驅動程式是否正確實現了媒體 API

型別

工具

V4L2 驅動程式[3]

v4l2-compliance

V4L2 虛擬驅動程式

contrib/test/test-media

CEC 驅動程式

cec-compliance

正在開發其他合規性工具以檢查子系統的其他部分。

這些測試需要在補丁進入上游之前透過。

此外，請注意我們使用以下方式構建核心

make CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1 CHECK=check_script

其中檢查指令碼是

#!/bin/bash
/devel/smatch/smatch -p=kernel $@ >&2
/devel/sparse/sparse $@ >&2

確保不要在補丁中引入新的警告，除非有非常好的理由。

1.2.1. 樣式清理補丁

當樣式更改會影響的檔案中與其他更改一起出現時，歡迎進行樣式清理。

我們可能會接受純粹的獨立樣式清理，但理想情況下，它們應該是整個子系統的一個補丁（如果清理量很小），或者至少按目錄分組。因此，例如，如果您在 drivers/media 下的驅動程式中進行大的清理更改集，請為 drivers/media/pci 下的所有驅動程式傳送一個補丁，為 drivers/media/usb 傳送另一個補丁，依此類推。

1.2.2. 編碼風格附錄

媒體開發使用嚴格模式下的 checkpatch.pl 來驗證程式碼風格，例如

$ ./scripts/checkpatch.pl --strict --max-line-length=80

原則上，補丁應該遵循編碼風格規則，但如果有充分的理由，則允許例外。在這種情況下，維護者和審查者可能會質疑不處理 checkpatch.pl 的理由。

請注意，這裡的目標是提高程式碼的可讀性。在少數情況下，checkpatch.pl 實際上可能指向看起來更糟的東西。因此，您應該使用良好的判斷力。

請注意，單獨處理一個 checkpatch.pl 問題（任何型別的）可能會導致每行的長度超過 80 個字元。雖然這並非嚴格禁止，但應努力保持在每行 80 個字元以內。這可能包括使用重構程式碼，從而減少縮排、更短的變數或函式名稱，最後但並非最不重要的一點是，只需換行即可。

特別是，我們接受超過 80 列的行

  • 在字串中，因為它們不應由於行長度限制而被中斷；

  • 當函式或變數名稱需要有大的識別符號名稱時，這使得難以遵守 80 列限制；

  • 在算術表示式中，當換行使它們更難閱讀時；

  • 當它們避免行以左括號或左方括號結尾時。

1.3. 關鍵週期日期

可以在任何時候傳送新的提交，但如果它們打算命中下一個合併視窗，則應在 -rc5 之前傳送，並且理想情況下在 -rc6 之前在 linux-media 分支中穩定。

1.4. 審查節奏

假設您的補丁位於 https://patchwork.linuxtv.org，它應該遲早會被處理，因此您無需重新提交補丁。

除了錯誤修復外，我們通常不會在 -rc6 和下一個 -rc1 之間向開發樹新增新補丁。

請注意，媒體子系統是一個高流量子系統，因此我們可能需要一段時間才能審查您的補丁。如果您在幾周內沒有收到反饋，或者要求其他開發人員公開新增 Reviewed-by 標籤，更重要的是，新增 Tested-by: 標籤，請隨時 ping 我們。

請注意，我們期望 Tested-by: 的詳細描述，說明在測試中使用了哪些板以及測試的內容。