大家好，我是小程程
看看下面這些話，能腦補出畫面麼？
1、 containing the disgusting "hdrtest" crap | 包含了令人作嘔的hdrtest垃圾程式碼2、 This thing needs to die | 這玩意必須死。3、 Don't make everybody else see that disgusting thing and have those turds in their trees. | 別讓大家看到這些噁心的東西，別讓程式碼樹裡出現這些垃圾。
嘿嘿，是不是對味了？
最近 Linux 之父 Linus 又罵人了。大佬的熟悉風格又回來了。
一、Linus 為什麼發火？
2025 年 3 月 28 日（週五），Linux 6.15 核心合併了大規模開源圖形驅動更新，本是核心社群的常規版本迭代，卻因一段測試程式碼引發核心開發者爭議。
29 日凌晨 00:47，Linus 在郵件列表中罕見發飆，公開批評被納入核心構建的
hdrtest事件導火索是該程式碼在常規核心構建中產生的副作用：不僅拖慢全模組配置構建速度，還在系統包含目錄遺留大量無用檔案，甚至導致 Git 狀態檢查報錯和檔名補全功能失效。
Linus 強調，這類測試程式碼不應作為常規構建的一部分，更不該破壞開發者的工作環境。
二、hdrtest 程式碼是什麼？為何激怒 Linus？
看似與「高動態範圍 (HDR)」相關的命名極具迷惑性，實際這裡的「HDR」指的是 C 語言標頭檔案（Header Files）。
這段程式碼隸屬於 Intel Xe 核心驅動，核心功能是驗證 DRM（直接渲染管理器）標頭檔案的自包含性，確保其透過核心文件測試，本質上是驅動模組的基礎維護工具。
觸怒 Linus 的 3 個點：
-
構建流程越界：測試程式碼被嵌入常規核心構建流程，導致所有開發者在執行全模組編譯時都需額外處理冗餘任務，違背「按需執行」的 Linux 開發哲學。
-
汙染原始碼生態：隨機生成的 hdrtest 檔案殘留在 include 目錄，破壞原始碼樹整潔性，Git 工具鏈無法有效識別排除，直接影響開發體驗。
-
技術實現硬傷：檔案殘留問題不僅是視覺汙染，更導致 IDE 檔名補全功能異常，觸及開發者工作效率的核心痛點。Linus 特別指出：「加入 gitignore 不是解決方案，只是掩耳盜鈴。」
更深層的開發原則衝突
這暴露出核心開發中「基礎設施汙染」的長期爭議——非核心功能程式碼如何正確整合？
Linus 強調，測試工具應保持模組化，透過獨立目標（如 make drm-hdrtest）按需執行，而非強制融入主構建流程，避免對無關開發者造成干擾。
三、Linus 的解決方案：從緊急止損到長期規範
1. 立即行動：標記 BROKEN 停用
作為臨時解決方案，Linus 已將該程式碼標記為 BROKEN 狀態，在 6.15 核心中直接停用，阻止其繼續汙染構建流程。
這一操作雖簡單粗暴，卻快速切斷問題程式碼的影響鏈條。
2. 長期規範：測試工具模組化設計
他明確提出改進方向：
-
構建流程解耦：測試程式碼應作為獨立目標存在，透過專用命令（如 make drm-hdrtest）單獨執行，而非捆綁常規編譯流程
-
原始碼樹潔癖原則：禁止在核心程式碼目錄生成任何臨時檔案，依賴外部測試框架處理中間產物
-
社群協作準則：功能模組需充分評估對非相關開發者的影響，避免因"區域性便利"造成"全域性汙染"
3. 給開發者的啟示
此次事件折射出核心開發的黃金法則：保持程式碼優雅、尊重開發生態、恪守最小干擾原則。即便是基礎維護工具，也需遵循「模組化、可配置、自清潔」的設計標準。
這場圍繞 hdrtest 程式碼的爭議，本質上是技術理想主義與工程實踐的碰撞。Linus 的憤怒不僅針對具體程式碼問題，更在捍衛 Linux 核心開發的核心準則——在追求功能完善的同時，必須守護程式碼生態的健康與優雅。對於開發者而言，這既是一次生動的程式碼規範課，也是理解開源社群協作機制的絕佳案例。
總之一句話：Linus 罵得對。
最後
附上 Linus 的回覆原文，一起圍觀學習：
傳送門：https://lore.kernel.org/dri-devel/174321011387.3019715.1646591159826097779.pr-tracker-bot@kernel.org/T/#t
– EOF –
