# 第 N 次貢獻 Linux 核心
> 本文僅供參考，請以 Kernel 官方文件： [Submitting patches: the essential guide to getting your code into the kernel](https://www.kernel.org/doc/html/latest/process/submitting-patches.html#submitting-patches-the-essential-guide-to-getting-your-code-into-the-kernel) 為主

contributed by < [`EricccTaiwan`](https://github.com/EricccTaiwan) >

> 本文重點不在於「如何尋找貢獻機會」，而是當找到可改進之處，該如何順利貢獻到 Upstream！

本文基於個人參與開源專案的經驗彙整。雖然有些做法比較「土法煉鋼」，但都是實際累積的心得，未來也會持續更新優化。(e.g., 補上 [`b4`](https://b4.docs.kernel.org/en/latest/) 使用心得)

> 註：[lore.kernel.org](https://lore.kernel.org/all/) 是記錄所有的信件往來，信件數量並不等同於實際的貢獻量，最終還是要以 [Mainline Kernel](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/) 為準。
> - [我的 Kernel 貢獻](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Cheng-Yang+Chou)
> - [我的 LKML 參與](https://lore.kernel.org/all/?q=yphbchou0911)

> 本文若有錯字，或描述錯誤，歡迎直接修正，謝謝！

## git clone linux

首先到 [git.kernel.org](https://git.kernel.org/) 尋找目標 tree。最簡單的方式是直接 clone [Linus 的 mainline tree](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/)。

:::spoiler 進階：子系統 SCM
> Most subsystem maintainers run their own trees and want to see patches prepared against those trees. See the `T:` entry for the subsystem in the MAINTAINERS file to find that tree, or simply ask the maintainer if the tree is not listed there.

可以在 Maintainer List 上找到各個子系統的 SCM，以免改動過時。
:::


個人習慣用 [Google Git](https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git) 來下載，速度快且穩定，連 `--depth` 都不用設定

$ git clone https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux

:::spoiler 成大網路實測約 6 分鐘

$ # 加上 time 測時間
$ time git clone https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux 
Cloning into 'linux'...
remote: Sending approximately 2.25 GiB ...
remote: Counting objects: 8348, done
remote: Finding sources: 100% (2786/2786)
remote: Total 11410156 (delta 9656158), reused 11409127 (delta 9656158)
Receiving objects: 100% (11410156/11410156), 2.25 GiB | 22.75 MiB/s, done.
Resolving deltas: 100% (9656158/9656158), done.
Checking objects: 100% (33554432/33554432), done.
Updating files: 100% (93013/93013), done.
1272.94user 190.96system 6:00.91elapsed 405%CPU (0avgtext+0avgdata 2325816maxresident)k
                         ^^^^^^^^^^^^^^
0inputs+8976632outputs (0major+2586062minor)pagefaults 0swaps

:::

## 貢獻機會
> 或許 Kernel 其他子系統也有 Good First Issue，待補充

- [Linux 核心設計 (Linux Kernel Internals)](https://wiki.csie.ncku.edu.tw/linux/schedule)
- Rust-for-Linux (R4L): [Good First Issue](https://github.com/Rust-for-Linux/linux/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22)
> 參考: [[RFC PATCH v2] rust: list: Add examples for linked list](https://lore.kernel.org/all/[e-mail]/) - I Hsin Cheng
- 關注各個子系統：Office-hours (e.g., [Google Meet](https://lore.kernel.org/all/?q=meet.google))、[訂閱 Mailing List](https://subspace.kernel.org/subscribing.html#subscribing-to-lists)、參與 chat channel (e.g., irc、zulipchat、Discord)
> 參考：[List of maintainers](https://docs.kernel.org/process/maintainers.html#list-of-maintainers)
- 找 Bug ： [kernel test robot](https://lore.kernel.org/oe-kbuild-all/?q=kernel+test+robot) 、 [syzbot](https://lore.kernel.org/all/?q=syzbot)、[bugzilla](https://bugzilla.kernel.org/buglist.cgi?component=Kernel&order=changeddate%20DESC%2Ccomponent%2Cpriority%2Cbug_severity&product=Linux&query_format=advanced&resolution=---)
> 必須在 commit 加上 `Reported-by: [Bug 連結]`
- 找註解中的 `TODO` 、 `Fix`
> 不過這些註解的或許頗有難度，
> > But it's like, if the TODO were so trivial that an AI could do it, then the original author could have done it.
>
> 見：[Re: [PATCH] media: atomisp: ov2722: move sensor init from set_fmt to s_stream](https://lore.kernel.org/all/[e-mail]/#t)
- Minor Fix ：找程式碼或註解中的 Typo ，或修正不符合 [Coding Style](https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#coding-style-notes) 的規範。
> Typo Fix 建議加上 `-cc=[e-mail]` ([Jonathan Corbet](https://www.oreilly.com/pub/au/592))，[Jserv](https://wiki.csie.ncku.edu.tw/User/jserv) 老師說他是[非常友善的開發者](https://youtu.be/cjq0OuUeepA?t=872)，同時 Jonathan 也是 LWN 的共同創辦人!
>
> 不過每個子系統 Maintainer 對於 Minor Fix 的接受度不同。若沒被 merge 也不用太灰心，Minor Fix 換個子系統再找就有。

## git commit -sv
`-v` 會列出你的修改，看著寫 commit message 會比較方便。
> 參考：[提交第一份 Patch 到 Linux Kernel](https://hackmd.io/@steven1lung/submitting-patches)

在提交 commit 時，一律使用 `-s` 參數，這會在 commit message 最下方自動加上 `Signed-off-by: [中文名的英譯] <常用信箱>`。

Linux Kernel 社群嚴格要求每筆 commit 都必須附上**真實姓名** (中文名的英譯) 與信箱，一來是為了確保 commit 的責任歸屬，二來別人也無法抹滅或偷走你的貢獻。

> 參考： [The seven rules of a great Git commit message](https://chris.beams.io/git-commit)

Commit 須以下方形式呈現，

子系統: [標題]

[內文]

Signed-off-by: [中文名的英譯] <常用信箱>

> 參考：[Patch-Subject](https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#patch-subject)

Example Subject:

[patch 2/5] ext2: improve scalability of bitmap searching

> 參考 ： [Andrew Morton, “The perfect patch” (tpp).](https://www.ozlabs.org/~akpm/stuff/tpp.txt)

**錯誤示範**：[[PATCH] IRQ_NOTCONNECTED: fix typo in comment](https://lore.kernel.org/all/87bjt4tnjz.ffs@tglx/)

## git format-patch
> 針對每次改動建議開啟獨立的 branch。避免弄亂 base branch（例如 `for-7.1`），在產生 patch 時也更方便。
>
> 若直接在 base branch 上提交多筆 commit，必須依賴 `git format-patch -N` 來指定具體的 commit 數量；但若有額外開立獨立 branch，只需直接指定與 base branch 的差異即可（見下方）。

需要將 commit 轉換成 Patch 格式，以便寄給 Maintainer 與 Reviewer 們進行 review，

$ pwd
user/linux
$ # 產生 patch
$ git format-patch [base branch] -o [路徑]

> `-o` 是 `--output-directory` 的縮寫

假設我想基於 `origin/master` 之上的 commit 產生 Patch，並將它們集中存放到上一層的 `patch/` 目錄中：

user/
 |_ linux/
 \_ patch/

$ pwd
user/linux
$ # 基於 origin/master 上，產生 patch，並放到 user/patch/
$ git format-patch origin/master -o ../patch

> 強烈建議將 Patch 輸出到獨立的資料夾（如 `user/patch/`），若直接輸出在 `linux/` 中，不易於後續的操作。

執行後，就能在 `user/patch/` 目錄下看到以 `000N-****.patch` 命名的 Patch 檔案了。

:::info
寄出前必須通過 `checkpatch.pl` 檢查，否則會被 Reviewer 提醒甚至無視。

錯誤示範：[[PATCH 0/1] Makefile: Temporarily suppress -Werror=unused-result](https://lore.kernel.org/all/[e-mail]/)。
:::
> 參考 : [Checkpatch](https://docs.kernel.org/dev-tools/checkpatch.html#checkpatch)

$ pwd
user/linux
$ # 跑測試 
$ ./scripts/checkpatch.pl ../patch/*.patch

若有錯誤，請使用 `git commit --amend` 修改後重新產出 Patch。

## make -j$(nproc)
> 如果 Fix Typo 就可以不用編譯，但還是建議跑個心安。

:::danger
並非每個子系統都有額外的 CI，因此在寄出 Patch 之前，請確保你的改動至少能通過編譯。

$ pwd
user/linux/
$ make -j$(nproc) # 用所有 CPU 進行編譯

否則會收到以下回覆，
> please at least do build testing

錯誤示範：[[PATCH 0/4] sched_ext: Standardize preprocessor comment markers](https://lore.kernel.org/all/[e-mail]/)
:::

## 提交 patch 前的測試

Bulid 後的映像檔，可以用 QEMU 或是 [virtme-ng](https://github.com/arighi/virtme-ng) 進行測試，我常用的後者，

$ pwd
linux/
$ # 在改動的 branch 上
$ make -j$(nproc)
$ # 在 compile kernel 的目錄下，直接開啟 vng，會選擇直接最新的映像檔
$ vng -v
          _      _
   __   _(_)_ __| |_ _ __ ___   ___       _ __   __ _
   \ \ / / |  __| __|  _   _ \ / _ \_____|  _ \ / _  |
    \ V /| | |  | |_| | | | | |  __/_____| | | | (_| |
     \_/ |_|_|   \__|_| |_| |_|\___|     |_| |_|\__  |
                                                |___/
   kernel version: 7.0.0-rc2+ x86_64
   (CTRL+d to exit)
$ # 就可以新 build 好的 kernel 裡進行測試

可以進行快速的驗證與測試。
> 如果只是 Typo fix，可跳過此驗證步驟。

## 撰寫 Cover letter

$ # 加上 --cover-letter
$ git format-patch [base branch] --cover-letter -o [路徑]

加上參數後，目錄中會多出一個 `0000-*.patch` 的檔案，這就是 Cover Letter 概念類似於 GitHub 上發送 PR 時的 Readme 描述欄，可以在裡面詳細說明這組 commit 的整體作用、附上遇到的 bug 或測試的 log。

> [PATCH 0/N] 就是 Cover letter

### 寄送策略

1. 單筆 Commit 且描述明確（不須 Cover letter)：如果只寄送一筆 commit，且 commit message 已經足夠清楚，我通常不會寫 Cover Letter，而是直接寄送 Patch（e.g. 修正 typo）。
- [[PATCH v2] genirq: Fix typo in IRQ_NOTCONNECTED comment](https://lore.kernel.org/all/[e-mail]/) - 我的第一筆 commit!
- [[PATCH] selftests/sched_ext: Abort test loop on signal](https://lore.kernel.org/all/[e-mail]/#t)

2. 多筆 Commit 或需要額外補充（須 Cover letter)：如果是多筆 commit，或者單筆 commit 但背景脈絡較複雜，強烈建議附上 Cover Letter 來幫助 Reviewer 理解。
> 不過也有收過 Maintainer 的回覆，Single Patch 不該加上 Cover Letter。
- 單筆附 Cover Letter ： [[PATCH 0/1] selftests/sched_ext: Fix unused-result warning for read()](https://lore.kernel.org/all/[e-mail]/)
- 多筆附 Cover Letter ： [[PATCH 0/4] sched_ext: Standardize preprocessor comment markers](https://lore.kernel.org/all/[e-mail]/#r)
> What if 多筆 commit 沒附 Cover Letter? [[連結](https://lore.kernel.org/all/aareTeuAos9-Mg2c@gpd4/)]
:::spoiler 補充說明
這筆 4 筆 Patch，是參與 sched-ext 的 office-hour 時，聽到 Andrea Righi 說 Ingo Molnar 的 Patch，Tejun Heo 說 sched-ext 也要跟上清除 preprocessor directives。
會後，我在 slack 上詢問能否幫忙，見沒人回覆就直接發 Patch，並順利被 merge。
:::

## git send-email
:::danger
絕對不能使用 **Gmail** 參與 LKML (e.g. 寄送 Patch、文字回覆），見：[Gmail(TUI)](https://www.kernel.org/doc/html/latest/process/email-clients.html#gmail-web-gui)
:::

要使用 `git send-email`，首先必須設定好信箱的 SMTP，也強烈推薦搭配 `Mutt` 或 `NeoMutt` 這類 Terminal-based 的信箱來使用。

> 信箱設定步驟在此暫不贅述，參考
> - https://git-send-email.io/
> - [Mutt，非常快速的終端電子郵件客戶端](https://zh-tw.ubunlog.com/mutt%E5%AE%A2%E6%88%B6%E9%83%B5%E4%BB%B6%E7%B5%82%E7%AB%AF/)
> - [MUTT(TUI)](https://www.kernel.org/doc/html/latest/process/email-clients.html#mutt-tui)
> - [我的 Neomutt config](https://gist.githubusercontent.com/EricccTaiwan/451f68855e0c5d234d350c366eb07f50/raw/21ba84e63204b0b6a52e8138bcfb27ba08c9c21e/mutt-config)

### 該寄給誰？
準備好 patch 後，可以用 `linux/script` 查看這個 patch 要給誰：

$ pwd
user/linux
$ ./scripts/get_maintainer.pl -f [修改的檔案]
$ # 以 minheap 的改動為例
$ ./scripts/get_maintainer.pl -f lib/min_heap.c
Kuan-Wei Chiu <[e-mail]> (maintainer:MIN HEAP)
[e-mail] (open list:MIN HEAP)

$ # 寄信
$ cd ../patch
$ git send-email *.patch \
   -to=[e-mail] \
   -to=[e-mail]

> 參考 : [第一次給 Linux Kernel 發 patch](https://hackmd.io/@rhythm/BkjJeugOv)

或是參考 [List of maintainers](https://docs.kernel.org/process/maintainers.html)，找出負責該程式碼的 Maintainer 、 Reviewer 以及對應的 Mailing list。

以 `SCHED_EXT` 為例，收件對象會包含：

Mail: [-to=]
- 無

Reviewer: [信件要 -cc=]
- Tejun Heo <[e-mail]>,
- David Vernet <[e-mail]>,
- Andrea Righi <[e-mail]>, 
- Changwoo Min <[e-mail]>

Mailing list: [-to==]
- [e-mail]

:::info
信件 ***必須*** 符合以下規則：
- `-to=` 包含所有的 Maintainer 與 Mailing list
- `-cc=` 包含所有的 Reviewer
:::

因此，在 `user/patch/` 目錄下寄信的指令如下：

$ pwd
user/patch
$ # 可以不用 --cc 給自己，git 會自動 CC 給有 Signed-off-by 的人
$ git send-email *.patch \
  --to=[e-mail] \
  --cc=[e-mail] \
  --cc=[e-mail] \
  --cc=[e-mail] \
  --cc=[e-mail]

> 建議直接用 `*.patch` 寄送，確保所有 Patch 在 [LKML](https://lkml.org/) 的 Thread 順序正確。

順利寄出後，你的 Patch 就會出現在 [LKML](https://lkml.org/) 上了。你也可以到 [lore.kernel](https://lore.kernel.org/all/) 搜尋自己的信箱來追蹤信件狀態，或是搜尋 `https://lore.kernel.org/all/[Message-id]`，也可以直接在終端機中查看 `$ w3m https://lore.kernel.org/all/[Message-id]`

:::info
在自己的 Gmail 上面看，滿常發生 Patch 不再同一個 Thread 的問題，還是以 LKML 為主，LKML 也比較清楚。
:::

:::spoiler 特例 (e.g., `SCHED_EXT`)
使用上述方法，我查了一下 `SCHED_EXT` 的改動要寄信給誰，

$ # 測試 kernel/sched/ext.c 
$ ./scripts/get_maintainer.pl -f kernel/sched/ext.c 
Tejun Heo <[e-mail]> (reviewer:SCHEDULER - SCHED_EXT)
David Vernet <[e-mail]> (reviewer:SCHEDULER - SCHED_EXT)
Andrea Righi <[e-mail]> (reviewer:SCHEDULER - SCHED_EXT)
Changwoo Min <[e-mail]> (reviewer:SCHEDULER - SCHED_EXT)
Ingo Molnar <[e-mail]> (maintainer:SCHEDULER)
Peter Zijlstra <[e-mail]> (maintainer:SCHEDULER)
Juri Lelli <[e-mail]> (maintainer:SCHEDULER)
Vincent Guittot <[e-mail]> (maintainer:SCHEDULER)
Dietmar Eggemann <[e-mail]> (reviewer:SCHEDULER)
Steven Rostedt <[e-mail]> (reviewer:SCHEDULER)
Ben Segall <[e-mail]> (reviewer:SCHEDULER)
Mel Gorman <[e-mail]> (reviewer:SCHEDULER)
Valentin Schneider <[e-mail]> (reviewer:SCHEDULER)
[e-mail] (open list:SCHEDULER - SCHED_EXT)
[e-mail] (open list:SCHEDULER)

列出了所有 Linux scheduler 相關的 Maintainer 和 Reviewer，看了一下 sched_ext 開發者們的 patch 也都只 CC 和 sched_ext 相關的人，算是少數的特殊情況吧。
:::

## PATCH vN
> 每一次的版本更動，都必須有清晰的文字紀錄。

當收到 Maintainer 或 Reviewer 的修改建議後，與 GitHub PR 直接 `push` 更新不同，需要產生帶有 `[PATCH vN]` 前綴的新 Patch 來重新寄送。

$ # 使用 -subject-prefix="PATCH vN" 指定版本號
$ git format-patch [branch] --subject-prefix="PATCH v2" -o [路徑]

在發送新版本時，務必記錄版本的 Changelog ：

- **有** Cover Letter ：
在 Cover Letter 最下方列出版本差異，不需要去修改每個 commit message 本身。

    [改動敘述]
    
    Changes in v3:
    - 改動 C
    - Link to v2:
      [連結] /* 換行顯示，不然好長 */

    Changes in v2:
    - 改動 B
    - 改動 A
    - Link to v1: 
      [連結]

- [[PATCH v2 0/2] tools/sched_ext: Sync configuration with upstream](https://lore.kernel.org/all/[e-mail]/)
- [[PATCHSET v10] sched_ext: Fix ops.dequeue() semantics](https://lore.kernel.org/all/[e-mail]/) - Andrea Righi

- **無** Cover Letter ：直接在 Patch 檔案的 `---` 分隔線下方加上變更紀錄，參考：[Commentary](https://www.kernel.org/doc/html/latest/process/submitting-patches.html#commentary)。

    ...

    Signed-off-by: [中文名的英譯] <常用信箱>
    ---
    /* 加在這邊 */
    Changes in v3: 
    - 修正 ooo (大明 王)
    - Link to v2:
      [連結]

    Changes in v2: 
    - 新增 xxx (小明 王)
    - Link to v1:
      [連結]
    
     tools/testing/selftests/sched_ext/init_enable_count.c | 3 ++-
     1 file changed, 2 insertions(+), 1 deletion(-)

    diff --git a/tools/testing/selftests/sched_ext/init_enable_count.c 

- [[PATCH 0/1] selftests/sched_ext: Fix unused-result warning for read()](https://lore.kernel.org/all/[e-mail]/)
- [[PATCH v2 4/4] selftests/sched_ext: Add test to validate ops.dequeue() semantics](https://lore.kernel.org/all/aZoPTP9zLBoKBZRx@gpd4/) - Andrea Righi

## 後續溝通事宜 / Reply on LKML

### 純文字回覆
我習慣用 `Mutt` 進行純文字回覆。在 `Mutt` 中選要回覆的信，按下 `g` 可以回覆所有 `-to/-cc` 的人。打好草稿後按下 `y` 傳送，回覆就會同步出現在 LKML 上。
> 建議先練習使用 `Mutt` 寄信(給自己)、回信、寄送 Patch (我也該練習)，等等的操作。

---

### 用 Patch 回覆 (In-reply-to)
> 我還沒用過 `Mutt` 進行 Patch 回覆

有時你需要直接在討論串底下回覆更新後的 Patch。以我用 Patch 回覆 Andrea Righi 的 [Review](https://lore.kernel.org/all/aZoJgm2FS2MPvqyO@gpd4/) 為例，信件最下方會附上一串指令：

$  git send-email \
    --in-reply-to=[Message-id] \
    --to=... \
    --cc=... \
    /path/to/YOUR_REPLY (你修改好的 patch)

修改好 commit 並重新產出 Patch 後，在 Patch 所在的目錄下執行上述帶有 `--in-reply-to` 的指令，就可以用 Patch 回覆了。
- [[PATCH 1/1] selftests/sched_ext: Fix unused-result warning for read()](https://lore.kernel.org/all/[e-mail]/)

---

### FAILED on stable kernel

> 代補充

> 參考：[FAILED: patch "[PATCH] sched_ext: Remove redundant css_put() in scx_cgroup_init()" failed to apply to 6.12-stable tree](https://lore.kernel.org/all/2026031630-character-subsector-36b1@gregkh/)

---

### 回覆任意 Thread
在 LKML 討論頁面的最下方會有，

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
                                                     ^^^^^^^

點選 `mbox.gz` 直接下載，再用

$ # 解壓縮
$ gunzip PATCH-xxx.mbox.gz
$ # 用 mutt 打開
$ mutt -f PATCH-xxx.mbox

剩下步驟如上述，就能用 mutt 進行回覆了!

---

### Gentle Ping！
Reviewer 的信箱有一堆的 Patch ，信件被漏掉或暫時忽略是很正常的。我如果寄出後 7 天左右沒有收到任何回覆，就會 `Gentle Ping`。
- [[PATCH 0/1] Makefile: Temporarily suppress -Werror=unused-result](https://lore.kernel.org/all/aGD3e43_k3KRzK1O@eric-wcnlab/)

> 可以透過訂閱子系統的 Mailing List，體現一下 Maintainer/Reviewer 們信箱爆滿的感受

## 貢獻成功 !

當 Reviewer 審查完畢，在信件中回覆 `Reviewed-by:` / `Acked-by:` / `Signed-off-by:` 時，通常就代表你的 commit 準備好（或已經）被 merge 到 Maintainer 管理的 tree 了！

等到下一次的 Merging Window 關閉後，你的 commit 就會正式出現在 [Linus 的 branch](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/) 上了!

## 參考資料
- [submitting-patches.html#references](https://www.kernel.org/doc/html/latest/process/submitting-patches.html#references)
- https://www.slideshare.net/slideshow/coscup-2024-linux-submitting-to-upstream-linux/270793163#1
- https://hackmd.io/@steven1lung/submitting-patches - 龍哥讚讚
- https://hackmd.io/@yanjiew/linux2023q1-1st_contrib
- https://hackmd.io/@Max042004/first-linux-patch
- [Getting to Know the Linux Kernel: A Beginner's Guide - Kelsey Steele & Nischala Yelchuri, Microsoft](https://youtu.be/QatE61Ynwrw?si=2j_uUa8qIuJ6cQvf)

## GFI
> 之後有發現都會紀錄在這，貢獻完畢，記得幫我更新！

* [/* current track (kmaloc()'d */](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/amiflop.c#n194) : kmaloc -> kmalloc
* commit 5dbdb2d87c29 ("checkpatch: prefer strscpy to strlcpy") : 把 `strlcpy` 改成 `strscpy`，在 `tools/perf/*` 中有很多

## 工具介紹

### `b4`
可用下列指令下載 patch 來閱讀：

$ b4 am [[Message-ID]] # 只抓一個主題的 patch
$ b4 mbox [[Message-ID]] # 除了下載 patch 本身，連同這個 patch 的討論一起下載

Ref:
- [Submit a kernel patch with `b4`](https://www.youtube.com/watch?v=QBR06ml2YLQ)
- [Submit a follow-up patch with `b4`](https://www.youtube.com/watch?v=-Vld9aoFPwU)
- https://blog.csdn.net/qq_39665253/article/details/147260060

> 但好像在 LKML 的 thread 顯示會亂掉，目前還不太敢用，需要高人指點..

### `Mutt` / `Neomutt`
當 Gmail 漏掉回覆，但你需要在郵件列表（Mailing List）上維持對話串時，可以依照以下步驟操作：

1. 抓取對話串 (Fetch with `b4`)
使用 `b4` 工具從 lore.kernel.org 抓取整個對話串並儲存為單一 `mbox` 檔案。

$ # 抓取該 Message-ID 所在的整個對話串並存為 mbox 檔
$ b4 am <MESSAGE-ID> -o my_reply.mbox

2. 拆分郵件 (Split with `git mailsplit`)
將抓回來的 `mbox` 檔案拆解成獨立的郵件檔案，以便定位特定節點。

$ # 指定輸出目錄
$ mkdir -p split_mails
$ git mailsplit -o ./split_mails/ thread.mbox

3. 定義回覆對象 (Locate & Reply)
在 `split_mails/` 目錄下找到你想要回覆的那封郵件（可以用 `grep` 搜尋關鍵字或 `Message-ID`）。

如果你使用 `Mutt`/`neomutt`: 直接讀取該檔案並按下 `r` 回覆：

$ neomutt -f ./split_mails/000X

如果你使用 `git send-email`:
確保你在撰寫新郵件時，在 `Header` 加入 `In-Reply-To` 指向該郵件的 `Message-ID`，以維持 Threading。
> Youtube 有滿多影片介紹的

- [Email on the terminal with mutt](https://youtu.be/2jMInHnpNfQ?si=m87kqitdDKUpe0AL)

### [kernel-tools](https://github.com/kees/kernel-tools)

### [hackermail](https://github.com/sjp38/hackermail)

### [Sashiko](https://sashiko.dev/#/)
顯示 LKML 上 Patch 的狀態，不過還在開發中，沒有完全同步 LKML 上的 Patch。

## apply patch
> 代整理

$ b4 am abkNtYPMARqxXibW@gpd4

Grabbing thread from lore.kernel.org/all/abkNtYPMARqxXibW@gpd4/t.mbox.gz
Analyzing 5 messages in the thread
Looking for additional code-review trailers on lore.kernel.org
Analyzing 0 code-review messages
Checking attestation on all messages, may take a moment...
---
  ✓ [PATCH] bpf: Always defer local storage free
  ---
  ✓ Signed: DKIM/nvidia.com
---
Total patches: 1
---
 Link: https://lore.kernel.org/r/[e-mail]
 Base: applies clean to current tree
       git checkout -b 20260316_arighi_nvidia_com HEAD
       git am ./20260316_arighi_bpf_always_defer_local_storage_free.mbx
$ git am ./20260316_arighi_bpf_always_defer_local_storage_free.mbx

## 後記

每位 Maintainer 的風格喜好都不一樣 (e.g. commit 的前綴)，保險起見，先參考過去的 commit 寫法，再進行撰寫，減少後續的溝通成本。

「勿以善小而不為」

我在 Kernel 的[第一筆貢獻](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0128816c42b52c6ee339718621aeda85855cd3be)，其實也是只修了一個 typo。成大系統系（aka 造船系）畢業的我，都能參與 Kernel 貢獻了，相信各位愉快小夥伴一定都可以的！

「注意細節」

所有的 Kernel 參與經歷都是公開可見的，有可能一戰成名，也有機會被噴到出圈，因此這也是 [Jserv](https://wiki.csie.ncku.edu.tw/User/jserv) 老師一再強調的重點「注意細節」。

直到現在，每次寄信前我都還會再三確認，深怕有任何錯誤，不過也因為參與的次數比較多了，有慢慢減少寄 Patch 時的緊張感。

Have Fun!