Linuxカーネルにパッチを送ってみよう
Introduction
私が初めて自分用のPCを買ったときのOSはWindows98でした。
その時から世の中にはもうLinuxが存在しており、
Vine LinuxとかRedhat Linuxをインストールして動かしていた記憶があります。
その後IT業界にはいって業務でもLinuxを使うようになり、
いまでも日常的にLinuxは使用しています。
そんな付き合いが長いLinuxですが、以前からLinuxのOSS活動に参加してみたいと思っていました。
ですが、当然ながらディスカッションは英語のみ、
OSS活動（カーネル開発）に参加する方法やルールもよくわからず、
結局何もしていませんでした。
しかし、AI が進化した昨今では、英語でのやり取りや手順の理解といったハードルは大きく下がっています。
（もちろん、コードの正しさの検証や適切なタグ付けなど、最終的な責任は自分で負う必要があります）
本記事では、Linux カーネル開発に参加する具体的なフローと私が実際に経験したことについて解説します。
About Linux Kernel Development
かつての（私の勝手な）イメージ
- Linux カーネルは、すごいプログラマーしか触れない(高レベルの技術者が集まる)
- 達人たちにコード見せてめちゃくちゃに叩かれる
- メーリングリスト（LKML）が殺伐としている
- どうやってコード管理するのかよくわからない
など。
このイメージだと敬遠したくなります。
また、昔なにかの記事で見た以下のような内容も
「LinuxのOSS活動参加怖い」というイメージを強くします。
Linus Torvalds の有名な発言:
- 「This is garbage.」（これはゴミだ）
- 「I hope you all die a painful death.」（苦しみながら死ねばいいのに）
- F ワード連発のレビューコメント
- 技術批判 ≒ 人格攻撃に近い表現も多数
苦労してかいたコードを「ゴミ送ってくんな」といわれて
rejectされるケースを想像してみてください。
心を折られて二度とパッチを送ろうと思えません。
過去には、正しいコードを書くことが最優先で、感情や配慮は二の次という空気が
存在していたのは事実のようです。
実際に新規のコントリビュータが萎縮したりコミュニティの健全性が問題視されていましたが、
2018年頃にLinus 本人が公式に謝罪し、行動規範（Code of Conduct）が導入されました。
参考: LWN — Code, conflict, and conduct
現在でも厳格なレビュー文化は健在で技術的妥協はしない方針ですが、
↑のような恐ろしい雰囲気は一切ありません。
私が実際にパッチを送ってみた感想としても、威圧的なレビューは一切ありませんでした。
なので、ちゃんとルールにしたがって行動すればまったく問題ありません。
Why Use Mail?
すべてをGitHub で管理しているわけではない
Linux カーネルの開発は、GitHub が開発される前の 1991 年から続いています。
そして今でも、パッチのやりとりはメーリングリストで行われています。
（Issue 管理などで GitHub が使われているサブシステムもある）
メールでの開発は汎用性が高く、Linux規模の開発でも対応可能です。
| メリット | 説明 |
|---|---|
| オープン | すべての議論がアーカイブされ、誰でも閲覧可能 |
| 非同期コミュニケーション | 世界中の開発者が自分のペースで参加 |
| ツール非依存 | 特定のプラットフォームに縛られない |
| レビューの質 | インラインでコードを引用しながら詳細に議論 |
| スケーラビリティ | 年間数万件のパッチを処理可能 |
メール中心のワークフローについては、kernel.org の How the development process works と
Submitting patches: the essential guide に詳しく書かれているのでご確認ください。
なお、vger.kernel.org 系のリストは 投稿するだけならメーリングリストの購読（subscribe）は不要 です。自分のパッチへの返信は CC で届き、全スレッドは lore.kernel.org でも読めます。とはいえ、他の議論も追いたい・返信をメールで受け取りたい場合は購読しておくと便利です（購読可否や投稿の扱いはリストごとに例外があり得るので、対象リストの案内ページも確認してください）。
メールでのやりとり例
パッチを送ると、以下のようなメールがやりとりされます。
From: あなた
Subject: [PATCH] driver: fix null pointer dereference
ここにパッチの説明...
---
drivers/foo/bar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/foo/bar.c b/drivers/foo/bar.c
...
レビュアーからの返信:
On Mon, Dec 04, 2025 at 10:00:00AM +0900, あなた wrote:
> + if (!ptr)
> + return -EINVAL;
Looks good to me.
Reviewed-by: Reviewer Name <reviewer@example.com>
なお、すべてのやりとりは lore.kernel.org でアーカイブされ、
永続化されます。
Actual Development flow
開発フロー
Linux カーネルは巨大なプロジェクトなので、すべてを一人で見ることは不可能です。
そのため、後述するサブシステムごとにメンテナがいて、階層的に管理されています。
送られたパッチは以下のフローでメインラインにマージされます。
あなたのパッチ
↓
サブシステムメンテナ（例: ネットワーク、ファイルシステム、Rustなど）
↓
上位メンテナ
↓
Linus Torvalds（最終統合のみ）
完璧なコードでないと受け付けてもらえないのか？
送信されたパッチはレビューを通じて改善していくのが普通です。
最初から完璧なパッチを送る必要はありません。
レビュアーが「ここはこう直して」「こうしたほうがいい」とフィードバックをくれます。
それを受けて v2, v3 と改訂版を送るのが一般的な流れです。
[PATCH v1] 最初の提案
↓ レビューで指摘を受ける
[PATCH v2] 修正版
↓ さらに改善
[PATCH v3] 最終版 → マージ
v2, v3 の改訂版の送り方は kernel.org の Submitting patches — Respond to review comments と
The canonical patch format に基準が示されているので参考にしましょう。
どのくらいでマージされるのか？
どんなに軽微な修正でもマージには時間がかかります。
数週間から数ヶ月かかることは普通です。
Linux カーネルには「マージウィンドウ」という期間があり、新機能はこの期間にしか取り込まれません。
（2. How the development process works）
Sub System
カーネルは小さなプロジェクトの集合体になっている
Linux カーネルは 数千万行以上のコードがありますが、
実態は数百のサブシステムに分かれています。
| サブシステム | 担当領域 | メンテナ例 |
|---|---|---|
| net | ネットワーク | Jakub Kicinski、Paolo Abeni |
| fs | ファイルシステム | 各 FS ごと |
| drivers/* | デバイスドライバ群（多数のサブシステムを内包） | 各分野ごと（driver core は Greg Kroah-Hartman） |
| rust | Rust サポート | Miguel Ojeda |
| mm | メモリ管理 | Andrew Morton |
誰に送ればいいのか？
パッチを送る相手は、スクリプトで自動的に特定できます（Submitting patches — Select the recipients for your patch）:
./scripts/get_maintainer.pl your-patch.patch
簡単ですね。
パッチがマージされるまで
作成したパッチは、以下のようなフローでリリースに含まれます
（このフロー全体は 2. How the development process works で解説されている）:
1. パッチ送信 メーリングリストに送る
↓
2. レビュー Acked-by / Reviewed-by をもらう
↓
3. サブシステムツリー メンテナが取り込む（例: net-next, rust-next, usb-next）
↓
4. linux-next 全サブシステムをまとめて統合テスト
↓
5. マージウィンドウ Linus が mainline に統合（約2週間）
↓
6. RC 期間 バグ修正のみ（rc1 → … → rc6〜rc9、約6〜10週間）
↓
7. 正式リリース
タイムライン（目安）
| フェーズ | 期間 |
|---|---|
| レビュー | 1〜2 週間 |
| サブシステムツリー滞在 | 1〜4 週間 |
| linux-next テスト | 1〜2 週間 |
| マージウィンドウ待ち | 0〜10 週間 |
| RC 期間 | 6〜10 週間（公式 "six to ten weeks"、通常 rc6〜rc9） |
| 合計 | 2〜5 ヶ月 |
カーネルは安定性が最優先です。
焦らず待ちましょう。
Specific Steps for Submitting a Patch
ここからはいままでの解説を踏まえて、実際にパッチを送るときの一連の手順を見ていきます。
開発環境を用意する
Linux カーネルはホスト Linux 上でのビルドが基本です。
macOS / Windows ユーザーは VM か WSL を使うのが楽です。
私の場合 macOS 上で OrbStack を使って Ubuntu 24.04 VM を立てました。
※開発の種類によっては実機が必要なケースもある
最低限必要なもの:
- Linux環境（Ubuntu/Fedora 等。macOS なら OrbStack / Lima / UTMなど）
- ビルドツール:
build-essential、git、llvm/clang/lldなど必要なパッケージ git send-email: パッチをメールで送るための git 拡張
ディストリビューションごとの正確なパッケージ名や開発フローの全体像は、
Linux カーネル公式の HOWTO do Linux kernel development と Submitting patches を参照してください。
環境が整ったら、対象サブシステムのソースをクローンしましょう。
# 例: Rust for Linux サブシステム
git clone --branch rust-next https://github.com/Rust-for-Linux/linux.git
cd linux
Submitting a Patch
Linux カーネルへのパッチ送信(サブシステム問わず)の流れは
だいたい以下です。
Step 1. 取り組む題材を選ぶ
Linux カーネルには GitHub Issues のような Issue トラッカーはありません。
（GitHub を併用する一部サブシステムを除く）
そのため、取り組むテーマは自分で見つけにいくのが基本です。
題材の探し方例は以下。
- MAINTAINERS ファイル / 各サブシステムの公式 docs から興味のある領域を探す
lore.kernel.org過去スレッド を眺めて改善余地のある議論や TODO を見つける- ソース内の
TODO:/FIXME:コメント を grep で探す - 自分が普段使っているドライバ・サブシステム のドキュメントの誤りを発見する
なお、Rust for Linux など GitHub を併用するサブシステムに限っては
GitHub Issues（good first issue ラベル）で探すこともできます。
また、Zulip（rust-for-linux.zulipchat.com）で「これに取り組みたい／すでに着手者がいるか」を
相談すること可能。
最初はとりあえずタイポ修正やドキュメント改善から
パッチ送信のフローを体験してみるとよいかもしれません。
Step 2. 作業ブランチを作成
とりあえず作業用ブランチ作成。
git fetch origin
git checkout -b fix-something origin/<subsystem-branch>
Step 3. 修正する
- 1つのパッチで1つの変更が原則です（複数の論理的修正がある場合は別パッチに分割）
- コードスタイルは Linux Kernel Coding Style に合わせる
※Rustの場合は cargo fmt / rustfmt で整形
Step 4. コミット作成
git add <修正ファイル>
git commit -s -m "subsystem: short summary
<詳細な説明。変更理由・何を変更したか>
Reported-by: Reporter Name <email>
Closes: <Issue URL>"
必須タグは以下。
Signed-off-by:— DCO（Developer's Certificate of Origin） への同意。git commit -sで自動付与
※Submitting patches — Sign your work: the Developer's Certificate of Origin
場合によって付けるタグは以下。
Reported-by:— 問題を報告したバグ報告者 をクレジットするタグCloses:— GitHub Issue や類似のチケットを解決するときの参照 URLFixes:— 過去の特定 commit が原因の問題を直すときに、その原因 commit の SHA を入れるAssisted-by:— AI などの高度なコーディング支援ツールを使った場合は明記が必要（記載しないと採用の妨げになり得ると公式に明記されています。Using Assisted-by:）。書式はAssisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]（例:Assisted-by: Claude:claude-3-opus coccinelle sparse。詳細は AI Coding Assistants）
Reported-by: / Closes: / Fixes: の公式な定義は Submitting patches — Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: を参照。
なお、Closes: は Issue やバグ報告の URL を参照するためのタグです。報告者がいれば Reported-by: と併記し、過去の commit が原因なら Fixes: も付けます（状況に応じて併用）。
Step 5. パッチ生成
カーネル開発では、コミットをメールで送れる形式（.patch ファイル）に変換して送ります。
このステップでは、直前のコミットを git format-patch で 1 通のパッチに出力します。
出力ファイルにはコミットメッセージ・diff・diffstat が含まれ、受け取ったメンテナが
git am でそのまま取り込める形式になっています。
git format-patch --base=auto -1
# → 0001-subsystem-short-summary.patch
--base=auto を付けると、メンテナがどのブランチに当てるべきかを示す
base-commit 情報がfooterに入ります。
Step 6. checkpatch.pl で検証
./scripts/checkpatch.pl 0001-*.patch
ERROR は修正必須。WARNING は修正するか、修正しない明確な理由を記述しましょう。
公式の位置づけは Submitting patches — Style-check your changes に記載されています（機械的に全部潰すのではなく、残す違反は説明できる状態にするのが原則）。
Step 7. 宛先を決める
./scripts/get_maintainer.pl 0001-*.patch
出力されたメンテナとサブシステムのメーリングリストを必ず宛先に含めましょう。
--to と --cc の細かい振り分けはサブシステムごとの慣習に従うようにします。
※メンテナとサブシステムリストを --to、レビュアーと linux-kernel@vger.kernel.org を
--cc に置くのが普通みたいです
Step 8. テスト送信
いきなり送信せず、まず自分宛に送信してフォーマット崩れなどを確認しましょう。
git send-email --to=your-email@example.com 0001-*.patch
メールが正しく届くか、diff の整形が崩れていないか、From が正しいかなどをチェックします。
※Gmail などでは「インデントが崩れる」「> がプレフィックスとして付かない」などのトラブルが起きやすい
Step 9. 本番送信
get_maintainer.pl の出力を --to / --cc に展開して送信します。
git send-email \
--to="<Maintainer Name> <maintainer@example.com>" \
--to=<subsystem-list>@vger.kernel.org \
--cc="<Reviewer Name> <reviewer@example.com>" \
--cc=linux-kernel@vger.kernel.org \
0001-*.patch
メールを送信すると、数分〜数時間後くらいには lore.kernel.org で
パッチが公開されます。
GitHub Issue がある場合、対象の Issue に lore.kernel.org のリンクを貼っておきましょう。
送信時の細かい注意点については以下を参照してください。
Step 10. レビュー対応
レビュアーからの反応は概ね以下のいずれかが多いです。
Acked-by:/Reviewed-by:が付く → 前向きなシグナル（ただしマージ保証ではない。Acked-by:は「この部分は問題ない」という限定的な同意のこともある）- インラインで指摘 →
v2を作って再送 - 沈黙 → 数週間待つ。返事がなければ(丁寧に)リマインドのメールを送る
修正版（v2）を送るときは以下のフロー。
git commit --amend
git format-patch -v2 --base=auto -1
git send-email --to=... v2-0001-*.patch
-v2 を付けるとパッチタイトルが [PATCH v2] になり、レビュアーが識別しやすいです。
Impressions
実際に私が簡単なドキュメント修正でこの一連のフローを実施しました。
所感としては以下です。
- レビュアーはみな親切で簡潔に指摘をくれます。威圧的な感じはまったくありません
checkpatch.plを事前に通しておけば、レビューで規約違反を指摘されることはほぼなし- 簡単な修正であれば採用判断が早く、数日でサブシステムにマージされるかも
- 軽微な指摘（タグの冗長性など）であれば、メンテナがマージ時に直してくれることもある
コードの深い知識がなくても Linux カーネル開発のプロセスを体験できるので、
GitHub（対象サブシステムが GitHub で Issue 管理されていれば）の Issue リストで
「good first issue」タグがついているものを選んで実際にやってみるのがよいかもしれません。
good first issue タグがついている Issue は、
コードの深い理解がなくても貢献できるものが多く、以下のようなタイプのものがあります。
- ドキュメントやコメントのタイポ・文法エラーなど
- コードのリファクタリング
- 非推奨API・古いイディオムの置き換え
こういったものが、プロセスを学ぶには最適です。
なお、Linux カーネル全体としては GitHub Issues が標準入口ではないため、
各サブシステムの公式 docs や lore.kernel.org の過去スレッド 、
ソース内の TODO: FIXME:などから探すのがよくある手法のようです。
Interact with the Community
実際にパッチを送る（＝Linux カーネル開発に参加する）前に、
コミュニティの行動規範と流儀に目を通しておきましょう。
技術的に正しいことはもちろん大切ですが、それと同じくらい「礼儀をもってやり取りすること」が
レビューを円滑に進め、長く貢献を続けるためのベースになります。
最初に読むべき公式ドキュメント:
- Linux Kernel Contributor Covenant Code of Conduct — コミュニティの行動規範
- Code of Conduct Interpretation — その解釈・運用
そのうえで、やり取りの際は次の点を心がけましょう。
※OSS 活動全般に通じる基本
- 敬意を持って接する — 相手(自分も)は忙しいボランティアです。「要求」ではなく「お願い」の姿勢を意識する
- フィードバックに感謝する — 厳しい指摘も、コードを良くするための助言として受け止める
- 焦らない — 返信は数日〜数週間かかることも普通です。
- 質問は歓迎ですが、自分で調べてから — ドキュメントや過去スレッド（lore）を確認したうえで、具体的に聞きましょう
Summary
本記事では、Linux カーネル開発に参加する流れを一通り見てきました。
かつては恐ろしい世界というイメージがありましたが、行動規範導入以降その空気は変わっており、
ルールに沿って礼儀正しく振る舞えば、新規参加者でも問題なく貢献できます。
カーネル開発は今もメールベースで回っていますが、git send-email を使えば難しくありません。
巨大なプロジェクトを支えるため、コードは数百のサブシステムに分割され、
それぞれのメンテナがレビューし、linux-next での統合テストとマージウィンドウ／RC 期間を経て
mainline に取り込まれます。
最初は、ドキュメント改善やリファクタリングのようなパッチがおすすめです。
まずはこのプロセスを一度体験してみることが良いと思います。
今回解説したパッチ送信のフローは、AI（Claude Code や Codex など）の助けを借りれば、スムーズに実施できます。
環境構築や作成したパッチのセルフチェック、英語の翻訳など、
つまずきそうな部分については特に役立つと思います。
※コード修正を含め、すべてを AI に丸投げしろといっているわけではありません。最終的な検証と責任は自分で負います。
※AI などの支援ツールを使ってパッチを作成した場合は、コミットに Assisted-by: を付けて明記します（Step 4 参照）。
世界中で動く無数の Linux——サーバーやクラウドの内部に
自分の書いたコードが入っている、
そこに喜びを感じるなら、ぜひ Linux カーネル開発に参加してみてください。
References
パッチ投稿の公式手順（kernel.org docs）
- Submitting patches: the essential guide — パッチ作成・送信の本命ドキュメント
- Sign your work: the Developer's Certificate of Origin — DCO の正式テキスト
- Select the recipients for your patch — 宛先選び
- Style-check your changes —
checkpatch.plの使い方 - Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: — タグの公式定義
- AI Coding Assistants —
Assisted-by:タグの書式と使い方 - How the development process works / 2. How the development process works — マージウィンドウ / RC / 階層メンテナンス
- Linux Kernel Coding Style
- Email Clients Info for Linux —
git send-email含むメール送信周辺 - Linux Kernel Contributor Covenant Code of Conduct / Interpretation
- Linux Kernel Enforcement Statement
- MAINTAINERS file
入門・コミュニティ
- kernelnewbies.org
- LFD103: A Beginner's Guide to Linux Kernel Development
- lore.kernel.org — メーリングリストの公式アーカイブ
- LWN: Code, conflict, and conduct (2018) — 2018 年 Linus 謝罪 + CoC 導入の経緯
