【Linux】 Linus TorvaldsがRISC-Vパッチに激怒！その理由とLinuxカーネル開発現場のリアル

はじめに

2025年8月、Linuxカーネルメーリングリストに激震が走った。

創始者Linus Torvaldsが「Re: [GIT PULL] RISC-V Patches」のスレッドに返信し、その内容は極めて痛烈な拒否だった。

「RISC-V専用であるべきコードが、汎用ヘッダファイルを汚染している」

これは単なる設計ポリシーの逸脱ではない。カーネル全体の安定性に直結する問題だった──。

RISC-V とは？

• 読み方：リスク・ファイブ
• ざっくり言うと：無料で使えるCPUの設計図
• スマホやPCに入ってるCPU（IntelやARMなど）は、企業の特許に守られていて自由に使えない
• RISC-Vはオープンソースなので、誰でも無料で使ったり作ったりできる
• だから最近、中国やインド、大学、スタートアップでめちゃくちゃ注目されてる

今回の「Linusの拒否事件」を超ざっくり説明すると…

🧩 起きたこと

• RISC-V関係の開発者が、Linuxに向けて新しいコードを提出（パッチ）

• そのコードが「RISC-V専用のはずなのに、全体のファイルを汚すような書き方になっていた」

• Linus Torvalds（Linux創始者）ブチギレ

  • 「こんなコード、絶対通さない」
  • 「遅れて出してくるくせにゴミ品質とかありえん」
  • など、辛辣なコメントを返す

なにが問題か？

• 共通で使うはずのファイルに、RISC-V専用の変更を入れていた

  • → 他のCPUアーキテクチャ（ARMやx86）に迷惑をかける

• Linuxの設計哲学に反していた

  • → どのアーキテクチャも、影響範囲を最小限にするのが鉄則

• ✅ RISC-V開発者：「新しい機能つけたから、Linuxに取り込んで！」
• ❌ Linus：「コードが汚すぎて無理。もっとちゃんと作って出して」

この騒動の意味

• RISC-Vの今後に不安？ → 違います。むしろ成長途中の証拠
• Linuxは世界中のコンピュータの土台なので、どのコードも超厳しい審査がある
• Linusは、適当なコードを「見逃さない人」で有名

まとめ一言でいうと…

「RISC-V専用のコードを出したけど、他の人の迷惑になる書き方だったから、Linusに全力で拒否された」
でもそれは、Linuxをきれいに保つための当然のやり取りです。

情報元と現状まとめ

• Linus Torvaldsのコメント内容

  • ヘルパー関数 make_u32_from_two_u16() を含むコードが、「汎用ヘッダーを汚染している」と強い調子で批判されています。(Phoronix)
  • 提出がマージウィンドウの最後で遅すぎた点も満足できない理由として述べられています。(Tom’s Hardware, Phoronix)
  • Linusは「このコードはゴミだ」と断言し、「世界を積極的に悪くする」とまで表現しています。(lwn.net)

• 背景報道

  • PhoronixやTechSpotなどの技術ニュースは事件全体の背景とコメントの文脈をまとめています。(Phoronix, TechSpot)
  • Merge Windowの締め切り直前の提出だった点、RISC‑V特有のコードが汎用部分に混じっていた点が問題視されています。(news.itsfoss.com)

① 該当パッチ内容の特定と差分分析

関連スレッドの概要

• 提出者：Palmer Dabbelt（RISC‑V メンテナ／Google → Meta 担当者）による「RISC‑V向けパッチ」
• 対象バージョン：Linux 6.17 のマージウインドウ向け
• Linusの反応：「ガベージ（garbage）」と表現し、即刻拒否。

問題箇所の核心：make_u32_from_two_u16() ヘルパー関数

Linusはこの関数の存在を特に問題視していました：

“Like this crazy and pointless make_u32_from_two_u16() ‘helper’. That thing makes the world actively a worse place to live. It’s useless garbage that makes any user incomprehensible, and actively WORSE than not using that stupid ‘helper’.” (Phoronix)

さらに……

“If you write the code out as (a << 16) + b, you know what it does … In contrast, if you write make_u32_from_two_u16(a,b) you have not a f%^5ing clue what the word order is.” (Phoronix)

要点まとめ：

「遅すぎ & 品質も問題」— Linusの切実な指摘

Linus本人も主張していました：

“No. This is garbage and it came in too late. I asked for early pull requests because I’m traveling … And by ‘garbage’ I really mean it.” (Tom’s Hardware) “You’re on notice: no more late pull requests, and no more garbage outside the RISC‑V tree.” (Phoronix)

言葉はきついですが、開発プロセスを守るために必要な警告でもあります。

② 背景説明：Linuxの開発プロセス（マージウインドウ）

Linux カーネル開発のリズム

Linuxカーネルは、約 3ヶ月ごとに新バージョンをリリースしています。この開発プロセスの心臓部が「マージウインドウ（Merge Window）」です。 これは、新機能や大規模変更を反映するための2週間限定の窓口 であり、その後は安定化フェーズへ移行します。(www.slideshare.net)

マージウインドウとは？

なぜこのリズムが重要なのか？

• 安定性確保：新機能は集中して取り込み、それ以外の期間はバグ修正に注力。計画的な安定への移行が可能になります。(Linuxカーネルドキュメント)
• 品質管理：マージウインドウ外の新機能や大きな変更は原則拒否され、次サイクル以降まで見送られるのが基本です。(yarchive.net, Linuxカーネルドキュメント)
• コミュニティ・開発文化：このルールは、Linuxカーネルの開発文化の基盤であり、Linusの強烈な拒否コメントもその品質維持の一貫と言えます。

過去の例：6.10・6.11 の状況

• Linux 6.10：マージウインドウでは11,534件もの変更がメインラインに取り込まれ、その後も大量の機能追加が続きました。RISC-V に Rust 対応が追加されたのもこの期間です。(Reddit, lwn.net)
• Linux 6.11：開始から数日で既に4,072件の変更がマージされており、その活気ぶりが窺えます。(lwn.net)

要約（まとめ）

マージウインドウは、Linuxカーネル開発における「新機能をまとめて取り込む黄金の2週間」。この期間に提出されるコードは、高品質・事前にテスト済みであることが求められます。それ以外の期間に出された「遅い提出」は、Linusから拒否される基盤がここにあります。

③ 問題のパッチ内容（ディフ解説）

パッチ概要と問題の焦点

• 提出者：Palmer Dabbelt（RISC‑Vメンテナー、Google／Meta）

• 対象バージョン：Linux 6.17 マージウインドウ（締切直前の金曜日）

• 主な問題点：

  • 汎用ヘッダーに、RISC‑V専用以外のコードを追加したこと
  • make_u32_from_two_u16() という “helper” 関数の導入が可読性を損ね、混乱を招く設計だった点 (Phoronix, Tom’s Hardware)

コード差分のイメージ（擬似ディフ）

--- a/include/linux/generic_header.h
+++ b/include/linux/generic_header.h
@@ -100,6 +100,12 @@
 // ... 既存コード

+// RISC‑V helper: combine two u16 into u32
+static inline u32 make_u32_from_two_u16(u16 high, u16 low) {
+    return (u32)high << 16 | low;
+}
+
+// end of RISC‑V helper

問題点まとめ：

• 配置場所が誤り：この関数はRISC‑V専用であり、汎用ファイル（generic_header.h）にはミスリードになる変更が含まれてしまった。

• 可読性・利用優位性の欠如：

  「（a « 16）+ b」と記述すればすぐ理解できるが、make_u32_from_two_u16(a,b)では引数の順序すら想像がつかない。これは「世界を積極的に悪くする」愚行だ。 (Phoronix)

Linus Torvaldsの批判点を深掘り

これらはLinusの技術的主張だけでなく、「プロセスを守れ」という規律面からの強い警告でもあります (Tom’s Hardware)。

棄却の流れとコミュニティ反応

• Linusはこの “helper” の導入に強く反発し、「早く・きれいな形で再提出するよう」求めました。次回は Linux 6.18 マージウインドウへの提出が許容される見込みです (Phoronix, ザ・レジスター)。
• Redditなどでは、この批判に対し「Linusの指摘は正しい」「だが言葉が過激すぎる」と賛否両論。多くの開発者がこのケースを通して「品質とタイミングの重要性」を再認識しています (Reddit)。

④ Linus のレス全文掲載と議論の焦点

メーリングリストでのLinusの主張（原文含む）

Linuxカーネル開発メーリングリスト（LKML）において、Linus Torvalds は以下のように強烈に反応しました：

“No. This is garbage and it came in too late. I asked for early pull requests because I’m traveling, and if you can’t follow that rule, at least make the pull requests good. This adds various garbage that isn’t RISC‑V specific to generic header files. And by ‘garbage’ I really mean it. This is stuff that nobody should ever send me, never mind late in a merge window. Like this crazy and pointless make_u32_from_two_u16() ‘helper’. That thing makes the world actively a worse place to live. It’s useless garbage that makes any user incomprehensible, and actively WORSE than not using that stupid ‘helper’. If you write the code out as ‘(a « 16) + b’, you know what it does and which is the high word. Maybe you need to add a cast to make sure that ‘b’ doesn’t have high bits that pollute the end result, so maybe it’s not going to be exactly pretty, but it’s not going to be wrong and incomprehensible either.” (Reddit, ウィキペディア, Phoronix)

議論の主な焦点ポイント

1. タイミングの問題

Linusは明確に、マージウィンドウ期間中の遅すぎる提出に強い不満を持っていました。自身が「旅行中である」ことを前提に「早めに提出すること」を頼んでおり、間に合わない場合は「少なくとも質を担保しろ」と強調しています。(Phoronix, Tom’s Hardware)

2. コード品質と設計指針の逸脱

• RISC‑V に固有の変更を、汎用のヘッダファイルに混ぜること自体が間違いだと批判。
• make_u32_from_two_u16() のようなヘルパー関数は、意図が分かりにくく、コードの可読性を下げるだけでなく、混乱を招くと非難。(Phoronix)

3. 発言の強烈さと差し迫った意図

• Linusは「garbage（ゴミ）」という言葉を重ねて強調。「世界を積極的に悪くする」（actively a worse place to live）という衝撃的な表現まで用いて、コード品質とプロセス遵守への強い信念を示しました。(Phoronix)

コミュニティからの反応（redditより）

開発者コミュニティやReddit上では、次のような声が見られます：

“In contrast, if you write make_u32_from_two_u16(a,b) you have not a f%^%ing clue what the word order is… you just made things WORSE…” (Reddit)

“One can say code is unnecessary or unhelpful without using charged words like garbage. It adds no clarity. It just speaks to the sadistic streak in Linus…” (Reddit)

賛否両論ありますが、多く見解は「Linus の厳しさは品質を守るための文化でもある」といった理解に基づいています。

このセクションの意図

Linusの発言を原文で掲載することで、なぜここまで厳しい表現を用いたのかを読者に理解してもらうことが目的です。

また、単なる言葉尻への批判ではなく、開発プロセスとコード品質に対する責任感から来る発言である点を強調しています。

⑤ RISC‑Vとは：その概要とLinuxへの統合状況

• RISC‑Vとは？

• **RISC‑V（リスク・ファイブ）**は、**UCバークレー大学で2010年に開発が始まった、オープンな命令セットアーキテクチャ（ISA）**です。 → 独占的なx86やARMと違い、仕様はオープンソースライセンスで公開され、誰でも無償で利用・改変可能な点が最大の特徴です。(ウィキペディア)

• 2015年に「RISC‑V International」に改組され、現在では世界中に4,500以上のメンバーを持つ非営利団体が仕様の策定・普及を担っています。(RISC-V International)

• SiFive社はRISC‑Vの理念を商用展開し、チップIPを提供することで市場を牽引しています。(SiFive)

• Linuxとの関わり：どれくらい支援されてきた？

• Linuxカーネル本体へのRISC‑Vサポートは2017年から始まりました。つまり、それ以来メインラインに正式統合されています。(RISC-V International)

• 初期はkernel 4.15でアーキテクチャコア部分が追加され、kernel 4.19ではシミュレーション環境での起動に必要なドライバー群が整備されました。(risc-v-getting-started-guide.readthedocs.io)

• その後、Debianが2023年7月に正式にRISC‑V（riscv64）を公式サポートするアーキとして追加。(RISC-V International) → また、他のディストリビューション（Fedora, Ubuntu, Rocky Linux等）もRISC‑Vを対応対象に広げています。(dfrobot.com, rockylinux.org, ウィキペディア)

• 最近（2025年7月）では、RISC‑V向けのハードウェア基盤（RVA23プロファイル）が策定され、上流統合の足がかりとして機能。(RISC-V International)

• 現在のエコシステムと活用状況

• RISC‑Vはモジュール性の高いISA設計とオープン性から、AI向けの拡張やハードウェアカスタマイズがしやすい構造となっており、多様な用途へ活用されています。(SiFive)

• UEFI, ACPI対応やLinuxブート環境の整備も進み、実用的なOSが動かせるハードウェア基盤が整いつつあります。(ウィキペディア)

• RISC‑Vのタブレット（PineTab-V）が、Debian搭載で一般向けに販売開始されるなど、実際にLinux環境を日常的に使えるデバイスも登場しているのも大きな進展です。(Tom’s Hardware)

• まとめ：ここまでの道のりと意義

⑥ 今後の展望：6.18への再提出指示およびコミュニティ反応

6.18への再提出と条件

Linus Torvalds は、RISC‑V 向けパッチを Linux 6.17 に含めるのを断念。その代わり、次のリリース “6.18 マージウインドウの早期に、余計な要素なく潔く再提出すること” を指示しました。

“you get to try again in 6.18. EARLY in that merge window. And without the garbage.” (Tom’s Hardware, ザ・レジスター)

これは技術的な指摘だけでなく、提出タイミングとプロセス遵守の重要性を重く見たメッセージでもあります。

コミュニティの反応（全体からの声）

賛成の声：

• 「品質の低いコードを提出させないという意思表示が、Linuxの品質を保つ上で効果的だ」
• 「Linus自身が開発プロセス全体を支えている責任者だから、この強い口調にも説得力がある」 (Reddit)

批判／懸念の声：

• 「批判は必要だが、“garbage” や “actively a worse place to live”といった言葉遣いは、協力者を萎縮させるかもしれない」
• 「徹底した厳しさは正義だが、もう少し建設的に伝える表現も可能では？」 (Tom’s Hardware)

たとえば Reddit では、以下のような声も見られました：

“艱難辛苦を受け入れる覚悟がある開発者なら、この厳しさを理解できる” —反対意見もある一方で、プロジェクトの重要性を理解した厳しさと捉える声が多いです。 “彼の言葉は辛辣だけど、結果的に開発意識の向上には繋がるかも” (Reddit)

今後の影響と示唆

⑦ まとめ：今回の騒動が示す「品質と開発文化」

1. 結像：厳しい言葉に込められた意思

Linus Torvaldsの「garbage」発言はショックが大きいですが、裏には「Linux開発の根幹を守れ」という強いメッセージがあります。品質と適切な提出タイミングを守ることで、カーネルの安定性と将来性を支える文化が継承されていることが如実に表れました。

2. プロセスの重要性：マージウインドウが鍵

Linuxは「マージウインドウ」という限定された期間に大量の変更を受け入れ、それ以外の期間は安定化・バグ修正に専念する開発サイクルを回しています。このリズムを乱す「当日提出」は大きなリスクであり、厳しく拒否すべき事案です。

3. コード設計から読み取れる姿勢

make_u32_from_two_u16() のような汎用ファイルへの不要な追加は、「その場しのぎ」の仕事として見なされます。Linuxでは、コードが何をしているか直感的に理解できること、混乱を避け明文化された設計を尊重する姿勢が求められます。

4. 一部では「言葉が過剰」との声も

RedditやTechSpotなどでは、「もっと丁寧な表現でもよかった」「Linusの言葉遣いがキツすぎる」という意見も散見されました。

“ngl I would quit if my boss talked to me like this. I love firm feedback, but words like ‘Garbage’ and the overall tone is weirdly personal.” “The delivery is terrible, he is a bad person, really. But he is quite right.” (reddit.com, forums.theregister.com)

しかし多くは、「Linusのスタイルはプロジェクトの信頼性を支えるための厳しさ」と理解しており、厳しさこそがLinuxの品質を守る文化であるとの共通認識が強いようです。

結び：技術者への教訓

• 品質への妥協が、技術的負債を生む → どんなに小さなヘルパーでも、プロジェクトを後戻りさせるリスクがあります。
• ルールを守ることは、信頼を築くこと → 提出のタイミング・内容・形式すべてが評価されます。
• 開発者としての誇りと責任を持つことが重要 → 曖昧なコードや無責任な提出は、自分自身も苦しめます。

「Linus流」の厳しさを通して、オープンソース開発において“本質的に大事なこと”を改めて考えさせられる事例でした。

Linus Torvalds calls RISC-V code from Google engineer 'garbage' and says it 'makes the world actively a worse place to live' — Linux honcho puts dev on notice for late submissions, too

Pull request got rejected for Linux 6.17. And as a late submission, it already lit Torvald’s fuse.

https://www.tomshardware.com/software/linux/linus-torvalds-calls-risc-v-code-from-google-engineer-garbage-and-that-it-makes-the-world-actively-a-worse-place-to-live-linux-honcho-puts-dev-on-notice-for-late-submissions-too?utm_source=chatgpt.com