狠狠撸

狠狠撸Share a Scribd company logo

向 Linux 核心上游提交更動 - Submitting Changes to Linux Kernel Upstream - COSCUP 2024

?
?
Chen-Yu Tsai
Chen-Yu Tsai

你對 Linux 核心開發有興趣嗎？你在工作上有向上游社群提交更動的需求嗎？想貢獻卻不知道怎麼進行嗎？本次議程將為各位介紹上游開發的流程，以及如何和社群互動。

1 of 37
ChromeOS 向 Linux 核?上游提交更動 COSCUP 2024/8/3 Chen-Yu Tsai (蔡鎮宇), ChromeOS 最後更新: 2024/8/5
ChromeOS Chinese Only ● If you were expecting a talk in English, I'm very sorry ● There are many other talks on this topic from various conferences available on YouTube
ChromeOS 聲明 ● 本次內容不代表雇主?場 ● 本次時間有限，僅快速帶過提交的流程 ○ 前半介紹的流程皆是參照官??件 ○ 後半介紹的後續為本?經驗 ● 不深?介紹指令如何使?
ChromeOS 前情提要 ● 2017年講過同樣的主題，?格不太?樣 ○ YouTube: COSCUP 2017 Linux Kernel Patch Submission Tips ○ 影? ○ 投影?
ChromeOS ?綱 ● 為什麼要向上游提交更動 ● 提交前的準備?作 ● 怎麼提交 ● 提交後
ChromeOS 為什麼要向上游提交更動 ● 分享成果 ● 降低後續升版維護負擔 ● 业主要求(?)
ChromeOS 提交前的準備?作
ChromeOS 準備電?信箱 ● 準備?個和上游社群互動?的電?信箱 ○ 能夠收到郵件論壇以及社群他?寄給你的信件 ○ 郵件寄出時不會竄改郵件內容 ■ 如隨意斷?、定位字元 (tab) 替換成空? ○ 郵件寄出時不會?動加上「機密?件」「保密」之類的警? ■ 所有的更動及討論都是公開的 ● 使?的郵件軟體或網站必須?援純?字信件 ○ 郵件論壇不收 HTML 信件 ○ 也不接受附件 ● 訂閱相關的郵件論壇 ○ 部份郵件論壇需要訂閱才能張貼
ChromeOS 抓取最新的程式碼 ● 第?次抓取的時候請務必先下載打包好的，以減輕伺服器負載 ○ https://www.kernel.org/cloning-linux-from-a-bundle.html ● 上游主線 (Linus Torvalds 維護) ○ git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ ● 下??版的整合樹 (linux-next) ○ git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ ● 基於何者開發視更動的性質做選擇 ○ 單純的錯誤修正 (bug ?x) 可基於主線 ○ 新功能、新硬體?援應基於下??版的整合樹 ● 提交前都應該更新到最新 ● 若是已經在其他版本上開發完成，則應該 rebase 到上列的分?上
ChromeOS 詳細描述所作的更動 ● 做了什麼修改簡單敘述就好 ● 重點在 為什麼 做這個更動 ○ 修正的錯誤如何重現 ○ 效能改善的數據 ○ 是否在設計上做了妥協 ● 是否對其他的更動有相依? ● 如果是修正，記得加 Fixes: xxxxxxxx ○ 考慮是否需要移植到穩定版 (backport to stable) ■ Cc: stable@vger.kernel.org ● 記得簽名 ○ Signed-o?-by: 名字 <電?信箱>
ChromeOS 拆分所作的更動 ● 每?筆 commit 應該 只做?件事 ○ 程式碼 原封不動 的搬移 ○ 修正錯誤 ○ 修改程式界?、函數參數等等 ○ 加?新功能 ○ 對多個檔案做 同樣 的修改
ChromeOS 檢查更動 ● 可以??做的檢查務必要做 ● 檢查程式碼?格 ○ 程式碼?格規則請看 Documentation/process/coding-style.rst ○ 使?到的資料結構或是函數，務必直接引?對應的標頭檔 ○ 使? Barrier 的時候務必加註解解釋?途 ● 執??動化檢查 ○ scripts/checkpatch.pl --strict <補丁檔 / 修改過的檔案路徑> ○ sparse ?具檢查 (教學?件) ■ 安裝 sparse 套件 ■ make C=1 ○
ChromeOS 檢查更動 - Device Tree 限定 ● Documentation/devicetree/bindings/dts-coding-style.rst ● 檢查規範?件的修改是否正確 ○ make dt_binding_check ● 檢查 device tree 是否符合規範?件 ○ make dtbs_check ● 使?技巧請看 教學 (英?)
ChromeOS 測試做好的更動 ● 測試?常的重要 ● 絕對要可以編譯 ○ 不同選項設定下也是 ■ 使?到的函數需要某個開啟選項，那選項關閉時是否還能正常編譯？ ● 實機測試 ○ 不可以弄壞別?的機?或環境 ○ 更動到韌體或是應?程式介?的時候必須向前相容
ChromeOS ?成補丁信件並寄出 ● git format-patch ?成補丁 ○ 絕對不是?其他指令再複製貼上 ● 如果?次要送的補丁超過?個，請務必撰寫說明信件 (cover letter) ○ git format-patch 加上 --cover-letter 可以連帶?出範本 ● git send-email 寄出 ○ 可能需要設定 SMTP 伺服器及認證資訊 ● 也有其他?具可以使?，但我沒?過 ○ patman ○ b4 ○ 使??法及?較請參考我同事的介紹 ■ Comparing and Contrasting Patman Vs B4 for Posting Patches - Doug Anderson, Google
ChromeOS 補丁寄出後
ChromeOS 等待... ● 社群散在世界各地，每個?時區不?樣，因此互動都是?即時的 ● 維護者看到也不?得會?上接受 ○ 保留時間給其他?審核、回應、測試 ● 維護者也會休假 ○ 歐洲?多半會放幾週的暑假 ○ 美國?會放感恩節、聖誕節 ○ 學?暑假或春假時，也可能全家?起休假 ● 維護者可能在忙其他事情 ● 因此，寄出後請?少等??兩週再詢問 ○ 有些維護者接受直接回覆原信件的詢問 ○ 有些維護者會希望直接重送
ChromeOS 收到回應 - 有錯誤 ● checkpatch 錯誤 ○ 改好後再送?版 ○ 表?該做的檢查沒做，務必避免 ● Does not apply - 無法套? ○ 選錯開發的基底版？ ○ 不夠新？ ○ 與別?的補丁有衝突？ ○ rebase 後再送?版
ChromeOS 收到回應 - 有錯誤 ● Build error ○ 修好後再送?版 ○ 表?該做的檢查沒做，務必避免 ● Build error w/ xxxcon?g - 某參數下編譯錯誤 ○ 設定選項 (Kcon?g) 相依?沒寫對？ ■ 使?到的函數或資料結構需要打開某個選項？ ■ 使?的函數不給模組使?？ ■ 平台或參數限定？ ○ 修好後再送?版
ChromeOS 收到回應 - NACK ● 維護者或審核者強烈反對 ○ 解法?向錯誤？ ○ 與現有系統設計理念不相容？ ○ 會造成現存系統故障？ ● 思考並與社群討論找出更適合的解法
ChromeOS 收到回應 - Looks good, but ... ● 審核者覺得還有改進空間 ○ 通常會伴隨著具體的建議 ○ 有不同的意?或是疑問，可以回信跟審核者討論 ● 審核者有疑問 ○ 務必要回覆審核者 ○ 不要置之不理直接送新版 ■ 審核者還是會提出?樣的問題，並且會不太爽 ● 修好後再送?版
ChromeOS 收到回應 - Applied ● 補丁被接受了，收? ● 過幾天看看有沒有出現在維護者的倉儲 (repository) 或是 linux-next ○ 維護者的樹通常在 git.kernel.org 上 ○ 顯?卡相關的可能在 gitlab.freedesktop.org 上 ○ 多媒體相關的可能在 git.linuxtv.org 上 ○ 有些制式回應會包含倉儲的 URL
ChromeOS 回信注意事項 ● 回信也是?純?字 ● 信件的 In-reply-to 標頭要是正確的 ● 不要更動引?的原? ○ 如果原?太?，則可以適度刪減 ○ 刪減時要註明有刪減 ■ "[...]" 或 "snip" 之類的寫法 ● 直接回在要回應的原?下 ○ 把他想成?個可以直接閱讀的對話
ChromeOS 回?接在原?下? On Sat, Dec 2, 2023 at 8:58 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Tue, Nov 28, 2023 at 12:45 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > @@ -61,6 +61,17 @@ con?g CHROMEOS_TBMC > > To compile this driver as a module, choose M here: the > > module will be called chromeos_tbmc. > > > > +con?g CHROMEOS_OF_HW_PROBER > > + bool "ChromeOS Device Tree Hardware Prober" > > Any reason that it can't be a module? No technical one. However if it's a module, the user has to manually load it. So I think it's more of a usability thing. OOTH I think this needs to be a module if I2C is built as a module. Somehow I had thought of it at one point but then it slipped my mind.
ChromeOS 再送新的?版 ● git format-patch -vN ● 務必附上更動歷史 ○ 記載每?版做了什麼變動 ○ 附在說明信件內，以及每個補丁內 ○ ?便審核者理解 ○ 更動歷史必須跟補丁變化符合 ● 審核者給的 Reviewed-by / Acked-by 記得加在??的 Signed-o?-by 後? ○ 但如果做了?幅度修改，則不要附上，並且註記為什麼沒有附上 ● 不要?天連續送好幾版 ○ 留時間給其他?回應
ChromeOS 社群、維護者、審核者、貢獻者、使?者 ● 社群裡多數?為志?，或是有其他職務要兼顧 ○ 共同?標是讓 Linux 更好，不管是提昇效能，或是在更多的硬體上可以執? ○ 聽到這裡了，你也是社群的?份? ● 審核者把關核?系統的架構和程式碼的品質 ○ 信件量很?，很難?上處理到，請有點耐? ● 不要浪費他?的時間，例如 ○ 不好好測試??的更動，把其他?當除錯器使? ○ 不理會其他?提出的疑問 ○ 惡意欺騙 ■ 把漏洞導?Linux核?來作實驗，Linux??封殺明尼蘇達?學所有貢獻| iThome
ChromeOS 社群、維護者、審核者、貢獻者、使?者 ● 社群以線上參與為主 ○ 即便是相同領域，甚?是同公司的同事，也不?得常常?? ○ ?年有幾次研討會可以?拜拜 ■ 如果有想要深耕這個領域，建議可以參加看看，台灣去的會眾實在不多
ChromeOS Q&A 後續的投影?有補充現場結束後詢問的問題
ChromeOS 回應審核者的意? ● 如果都沒有意?或要討論，還需要??回應 OK / "知悉" / "會改" 嗎? ○ 不?；全部改好直接送下?版就好了
ChromeOS 沒?理 / 沒有維護者 ● 有?理會的前提是有?有興趣、有共同的困難希望解決 ○ 去研討會或是透過業界組織 (Linaro 之類的) 找尋有類似問題的? ● 維護者?直消失怎麼辦？ ○ 如果?直都沒有?理的話，最後?招是寄給 Andrew Morton 請他收
ChromeOS Device Tree Binding 好難 ● Device tree binding 是呈現硬體的結構 ○ ?般常?的週邊 IP 都?同?異，因此審核者也可能依照已知的設計和?為模式去推敲 ○ 如果新的硬體設計?常的不同，或是有其妙迂迴的連結，務必在 commit 訊息中詳細解釋 ■ 這樣才不?跟審核者?直信件往來解釋 ■ 解釋不清楚就是?直跟審核者在雞同鴨講，浪費彼此時間
ChromeOS DT compatible string 到底怎麼訂? ● 以 "mediatek,mt8195-i2c", "mediatek,mt8192-i2c" 為例 ● 第?位置為 "最特定" 的識別字串 ○ 可能有增加了新功能 ○ 也可能僅是增加?個和 SoC ?樣的識別 ■ 這通常是為了留後路：如果事後發現有不相容的地?，不需要替換識別字串 ● 第?位置後的為 "完全向前相容" 的識別字串 (fallback) ○ 也就是說可以以?較舊的，僅?援舊版硬體的驅動程式控制硬體 ○ 可能無法使?最新的硬體功能，但既有的舊功能不受限 ○ 不管是硬體?為、硬體暫存器配置、硬體整合所需的資源 (power, clock, reset, etc.) ■ 只要有?點不同就是不相容 ● 如果和前代硬體有任何的不相容，則不應該第?位置後的識別字串
ChromeOS DT compatible string 到底怎麼訂? (續) ● ?般來說識別字串都是綁訂某顆晶? ○ 第?筆通常是最早出現這個 IP 的晶? ■ 或是最早被送上上游的... ○ 不應該有通?型的識別字串 ■ 即便是第三? IP，整合進晶?的?式也不盡相同 ● ?種例外是硬體型號可以完全透過軟體偵測 ○ 透過存有型號資料的暫存器 ○ 可能為同?系列硬體的不同配置 ■ 例如 GPU (例如 gpu/arm,mali-bifrost.yaml) ○ 整合?式?致，或是通?識別字串描述 IP 本?，特定識別字串描述整合差異 ■ "mediatek,mt8183b-mali", "arm,mali-bifrost" ■ 上列的 mt8183b 即為 binding 訂錯?必須更換識別字串的實例 ● 舊的 binding 仍需繼續?援
ChromeOS 謝謝
ChromeOS 參考資料 ● 送出第?個核?補丁 ○ https://kernelnewbies.org/FirstKernelPatch ● Linux 核?官??件 - 核?開發過程導覽 ○ 英? - Documentation/process/development-process.rst (網?版) ○ 繁體中? - Documentation/translations/zh_TW/process/development-process.rst (網?版) ○ 簡體中? - Documentation/translations/zh_CN/process/development-process.rst (網?版) ● Linux 核?官??件 - 提交補丁 ○ 英? - Documentation/process/submitting-patches.rst (網?版) ○ 繁體中? - Documentation/translations/zh_TW/process/submitting-patches.rst (網?版) ○ 簡體中? - Documentation/translations/zh_CN/process/submitting-patches.rst (網?版)
ChromeOS 參考資料 ● Linux 核?官??件 - 程式碼?格 ○ 英? - Documentation/process/coding-style.rst (網?版) ○ 繁體中?翻譯 - Documentation/translations/zh_TW/process/coding-style.rst (網?版) ○ 簡體中?翻譯 - Documentation/translations/zh_CN/process/coding-style.rst (網?版) ● Linux 核?官??件 - 提交前的檢查清單 ○ 英? - Documentation/process/submit-checklist.rst (網?版) ○ 繁體中?翻譯 - Documentation/translations/zh_TW/process/submit-checklist.rst (網?版) ○ 簡體中?翻譯 - Documentation/translations/zh_CN/process/submit-checklist.rst (網?版) ● COSCUP 共筆 ○ https://hackmd.io/b_6DmqbRTFeOO-7Y7UG1Mg ●
ChromeOS 中英?詞彙對照 ● 上游 ● 提交 ● 郵件論壇 ● 補丁 ● 提交 ● 倉儲 ● Upstream ● Submit ● Mailing list ● Patch ● Commit ● Repository

More Related Content

向 Linux 核心上游提交更動 - Submitting Changes to Linux Kernel Upstream - COSCUP 2024

  • 1. ChromeOS 向 Linux 核?上游提交更動 COSCUP 2024/8/3 Chen-Yu Tsai (蔡鎮宇), ChromeOS 最後更新: 2024/8/5
  • 2. ChromeOS Chinese Only ● If you were expecting a talk in English, I'm very sorry ● There are many other talks on this topic from various conferences available on YouTube
  • 3. ChromeOS 聲明 ● 本次內容不代表雇主?場 ● 本次時間有限，僅快速帶過提交的流程 ○ 前半介紹的流程皆是參照官??件 ○ 後半介紹的後續為本?經驗 ● 不深?介紹指令如何使?
  • 4. ChromeOS 前情提要 ● 2017年講過同樣的主題，?格不太?樣 ○ YouTube: COSCUP 2017 Linux Kernel Patch Submission Tips ○ 影? ○ 投影?
  • 8. ChromeOS 準備電?信箱 ● 準備?個和上游社群互動?的電?信箱 ○ 能夠收到郵件論壇以及社群他?寄給你的信件 ○ 郵件寄出時不會竄改郵件內容 ■ 如隨意斷?、定位字元 (tab) 替換成空? ○ 郵件寄出時不會?動加上「機密?件」「保密」之類的警? ■ 所有的更動及討論都是公開的 ● 使?的郵件軟體或網站必須?援純?字信件 ○ 郵件論壇不收 HTML 信件 ○ 也不接受附件 ● 訂閱相關的郵件論壇 ○ 部份郵件論壇需要訂閱才能張貼
  • 9. ChromeOS 抓取最新的程式碼 ● 第?次抓取的時候請務必先下載打包好的，以減輕伺服器負載 ○ https://www.kernel.org/cloning-linux-from-a-bundle.html ● 上游主線 (Linus Torvalds 維護) ○ git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ ● 下??版的整合樹 (linux-next) ○ git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/ ● 基於何者開發視更動的性質做選擇 ○ 單純的錯誤修正 (bug ?x) 可基於主線 ○ 新功能、新硬體?援應基於下??版的整合樹 ● 提交前都應該更新到最新 ● 若是已經在其他版本上開發完成，則應該 rebase 到上列的分?上
  • 10. ChromeOS 詳細描述所作的更動 ● 做了什麼修改簡單敘述就好 ● 重點在 為什麼 做這個更動 ○ 修正的錯誤如何重現 ○ 效能改善的數據 ○ 是否在設計上做了妥協 ● 是否對其他的更動有相依? ● 如果是修正，記得加 Fixes: xxxxxxxx ○ 考慮是否需要移植到穩定版 (backport to stable) ■ Cc: stable@vger.kernel.org ● 記得簽名 ○ Signed-o?-by: 名字 <電?信箱>
  • 11. ChromeOS 拆分所作的更動 ● 每?筆 commit 應該 只做?件事 ○ 程式碼 原封不動 的搬移 ○ 修正錯誤 ○ 修改程式界?、函數參數等等 ○ 加?新功能 ○ 對多個檔案做 同樣 的修改
  • 12. ChromeOS 檢查更動 ● 可以??做的檢查務必要做 ● 檢查程式碼?格 ○ 程式碼?格規則請看 Documentation/process/coding-style.rst ○ 使?到的資料結構或是函數，務必直接引?對應的標頭檔 ○ 使? Barrier 的時候務必加註解解釋?途 ● 執??動化檢查 ○ scripts/checkpatch.pl --strict <補丁檔 / 修改過的檔案路徑> ○ sparse ?具檢查 (教學?件) ■ 安裝 sparse 套件 ■ make C=1 ○
  • 13. ChromeOS 檢查更動 - Device Tree 限定 ● Documentation/devicetree/bindings/dts-coding-style.rst ● 檢查規範?件的修改是否正確 ○ make dt_binding_check ● 檢查 device tree 是否符合規範?件 ○ make dtbs_check ● 使?技巧請看 教學 (英?)
  • 14. ChromeOS 測試做好的更動 ● 測試?常的重要 ● 絕對要可以編譯 ○ 不同選項設定下也是 ■ 使?到的函數需要某個開啟選項，那選項關閉時是否還能正常編譯？ ● 實機測試 ○ 不可以弄壞別?的機?或環境 ○ 更動到韌體或是應?程式介?的時候必須向前相容
  • 15. ChromeOS ?成補丁信件並寄出 ● git format-patch ?成補丁 ○ 絕對不是?其他指令再複製貼上 ● 如果?次要送的補丁超過?個，請務必撰寫說明信件 (cover letter) ○ git format-patch 加上 --cover-letter 可以連帶?出範本 ● git send-email 寄出 ○ 可能需要設定 SMTP 伺服器及認證資訊 ● 也有其他?具可以使?，但我沒?過 ○ patman ○ b4 ○ 使??法及?較請參考我同事的介紹 ■ Comparing and Contrasting Patman Vs B4 for Posting Patches - Doug Anderson, Google
  • 17. ChromeOS 等待... ● 社群散在世界各地，每個?時區不?樣，因此互動都是?即時的 ● 維護者看到也不?得會?上接受 ○ 保留時間給其他?審核、回應、測試 ● 維護者也會休假 ○ 歐洲?多半會放幾週的暑假 ○ 美國?會放感恩節、聖誕節 ○ 學?暑假或春假時，也可能全家?起休假 ● 維護者可能在忙其他事情 ● 因此，寄出後請?少等??兩週再詢問 ○ 有些維護者接受直接回覆原信件的詢問 ○ 有些維護者會希望直接重送
  • 18. ChromeOS 收到回應 - 有錯誤 ● checkpatch 錯誤 ○ 改好後再送?版 ○ 表?該做的檢查沒做，務必避免 ● Does not apply - 無法套? ○ 選錯開發的基底版？ ○ 不夠新？ ○ 與別?的補丁有衝突？ ○ rebase 後再送?版
  • 19. ChromeOS 收到回應 - 有錯誤 ● Build error ○ 修好後再送?版 ○ 表?該做的檢查沒做，務必避免 ● Build error w/ xxxcon?g - 某參數下編譯錯誤 ○ 設定選項 (Kcon?g) 相依?沒寫對？ ■ 使?到的函數或資料結構需要打開某個選項？ ■ 使?的函數不給模組使?？ ■ 平台或參數限定？ ○ 修好後再送?版
  • 20. ChromeOS 收到回應 - NACK ● 維護者或審核者強烈反對 ○ 解法?向錯誤？ ○ 與現有系統設計理念不相容？ ○ 會造成現存系統故障？ ● 思考並與社群討論找出更適合的解法
  • 21. ChromeOS 收到回應 - Looks good, but ... ● 審核者覺得還有改進空間 ○ 通常會伴隨著具體的建議 ○ 有不同的意?或是疑問，可以回信跟審核者討論 ● 審核者有疑問 ○ 務必要回覆審核者 ○ 不要置之不理直接送新版 ■ 審核者還是會提出?樣的問題，並且會不太爽 ● 修好後再送?版
  • 22. ChromeOS 收到回應 - Applied ● 補丁被接受了，收? ● 過幾天看看有沒有出現在維護者的倉儲 (repository) 或是 linux-next ○ 維護者的樹通常在 git.kernel.org 上 ○ 顯?卡相關的可能在 gitlab.freedesktop.org 上 ○ 多媒體相關的可能在 git.linuxtv.org 上 ○ 有些制式回應會包含倉儲的 URL
  • 23. ChromeOS 回信注意事項 ● 回信也是?純?字 ● 信件的 In-reply-to 標頭要是正確的 ● 不要更動引?的原? ○ 如果原?太?，則可以適度刪減 ○ 刪減時要註明有刪減 ■ "[...]" 或 "snip" 之類的寫法 ● 直接回在要回應的原?下 ○ 把他想成?個可以直接閱讀的對話
  • 24. ChromeOS 回?接在原?下? On Sat, Dec 2, 2023 at 8:58 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Tue, Nov 28, 2023 at 12:45 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > @@ -61,6 +61,17 @@ con?g CHROMEOS_TBMC > > To compile this driver as a module, choose M here: the > > module will be called chromeos_tbmc. > > > > +con?g CHROMEOS_OF_HW_PROBER > > + bool "ChromeOS Device Tree Hardware Prober" > > Any reason that it can't be a module? No technical one. However if it's a module, the user has to manually load it. So I think it's more of a usability thing. OOTH I think this needs to be a module if I2C is built as a module. Somehow I had thought of it at one point but then it slipped my mind.
  • 25. ChromeOS 再送新的?版 ● git format-patch -vN ● 務必附上更動歷史 ○ 記載每?版做了什麼變動 ○ 附在說明信件內，以及每個補丁內 ○ ?便審核者理解 ○ 更動歷史必須跟補丁變化符合 ● 審核者給的 Reviewed-by / Acked-by 記得加在??的 Signed-o?-by 後? ○ 但如果做了?幅度修改，則不要附上，並且註記為什麼沒有附上 ● 不要?天連續送好幾版 ○ 留時間給其他?回應
  • 26. ChromeOS 社群、維護者、審核者、貢獻者、使?者 ● 社群裡多數?為志?，或是有其他職務要兼顧 ○ 共同?標是讓 Linux 更好，不管是提昇效能，或是在更多的硬體上可以執? ○ 聽到這裡了，你也是社群的?份? ● 審核者把關核?系統的架構和程式碼的品質 ○ 信件量很?，很難?上處理到，請有點耐? ● 不要浪費他?的時間，例如 ○ 不好好測試??的更動，把其他?當除錯器使? ○ 不理會其他?提出的疑問 ○ 惡意欺騙 ■ 把漏洞導?Linux核?來作實驗，Linux??封殺明尼蘇達?學所有貢獻| iThome
  • 27. ChromeOS 社群、維護者、審核者、貢獻者、使?者 ● 社群以線上參與為主 ○ 即便是相同領域，甚?是同公司的同事，也不?得常常?? ○ ?年有幾次研討會可以?拜拜 ■ 如果有想要深耕這個領域，建議可以參加看看，台灣去的會眾實在不多
  • 29. ChromeOS 回應審核者的意? ● 如果都沒有意?或要討論，還需要??回應 OK / "知悉" / "會改" 嗎? ○ 不?；全部改好直接送下?版就好了
  • 30. ChromeOS 沒?理 / 沒有維護者 ● 有?理會的前提是有?有興趣、有共同的困難希望解決 ○ 去研討會或是透過業界組織 (Linaro 之類的) 找尋有類似問題的? ● 維護者?直消失怎麼辦？ ○ 如果?直都沒有?理的話，最後?招是寄給 Andrew Morton 請他收
  • 31. ChromeOS Device Tree Binding 好難 ● Device tree binding 是呈現硬體的結構 ○ ?般常?的週邊 IP 都?同?異，因此審核者也可能依照已知的設計和?為模式去推敲 ○ 如果新的硬體設計?常的不同，或是有其妙迂迴的連結，務必在 commit 訊息中詳細解釋 ■ 這樣才不?跟審核者?直信件往來解釋 ■ 解釋不清楚就是?直跟審核者在雞同鴨講，浪費彼此時間
  • 32. ChromeOS DT compatible string 到底怎麼訂? ● 以 "mediatek,mt8195-i2c", "mediatek,mt8192-i2c" 為例 ● 第?位置為 "最特定" 的識別字串 ○ 可能有增加了新功能 ○ 也可能僅是增加?個和 SoC ?樣的識別 ■ 這通常是為了留後路：如果事後發現有不相容的地?，不需要替換識別字串 ● 第?位置後的為 "完全向前相容" 的識別字串 (fallback) ○ 也就是說可以以?較舊的，僅?援舊版硬體的驅動程式控制硬體 ○ 可能無法使?最新的硬體功能，但既有的舊功能不受限 ○ 不管是硬體?為、硬體暫存器配置、硬體整合所需的資源 (power, clock, reset, etc.) ■ 只要有?點不同就是不相容 ● 如果和前代硬體有任何的不相容，則不應該第?位置後的識別字串
  • 33. ChromeOS DT compatible string 到底怎麼訂? (續) ● ?般來說識別字串都是綁訂某顆晶? ○ 第?筆通常是最早出現這個 IP 的晶? ■ 或是最早被送上上游的... ○ 不應該有通?型的識別字串 ■ 即便是第三? IP，整合進晶?的?式也不盡相同 ● ?種例外是硬體型號可以完全透過軟體偵測 ○ 透過存有型號資料的暫存器 ○ 可能為同?系列硬體的不同配置 ■ 例如 GPU (例如 gpu/arm,mali-bifrost.yaml) ○ 整合?式?致，或是通?識別字串描述 IP 本?，特定識別字串描述整合差異 ■ "mediatek,mt8183b-mali", "arm,mali-bifrost" ■ 上列的 mt8183b 即為 binding 訂錯?必須更換識別字串的實例 ● 舊的 binding 仍需繼續?援
  • 35. ChromeOS 參考資料 ● 送出第?個核?補丁 ○ https://kernelnewbies.org/FirstKernelPatch ● Linux 核?官??件 - 核?開發過程導覽 ○ 英? - Documentation/process/development-process.rst (網?版) ○ 繁體中? - Documentation/translations/zh_TW/process/development-process.rst (網?版) ○ 簡體中? - Documentation/translations/zh_CN/process/development-process.rst (網?版) ● Linux 核?官??件 - 提交補丁 ○ 英? - Documentation/process/submitting-patches.rst (網?版) ○ 繁體中? - Documentation/translations/zh_TW/process/submitting-patches.rst (網?版) ○ 簡體中? - Documentation/translations/zh_CN/process/submitting-patches.rst (網?版)
  • 36. ChromeOS 參考資料 ● Linux 核?官??件 - 程式碼?格 ○ 英? - Documentation/process/coding-style.rst (網?版) ○ 繁體中?翻譯 - Documentation/translations/zh_TW/process/coding-style.rst (網?版) ○ 簡體中?翻譯 - Documentation/translations/zh_CN/process/coding-style.rst (網?版) ● Linux 核?官??件 - 提交前的檢查清單 ○ 英? - Documentation/process/submit-checklist.rst (網?版) ○ 繁體中?翻譯 - Documentation/translations/zh_TW/process/submit-checklist.rst (網?版) ○ 簡體中?翻譯 - Documentation/translations/zh_CN/process/submit-checklist.rst (網?版) ● COSCUP 共筆 ○ https://hackmd.io/b_6DmqbRTFeOO-7Y7UG1Mg ●
  • 37. ChromeOS 中英?詞彙對照 ● 上游 ● 提交 ● 郵件論壇 ● 補丁 ● 提交 ● 倉儲 ● Upstream ● Submit ● Mailing list ● Patch ● Commit ● Repository