轉自：InfoQ
1Asahi Linux 首席開發者 Hector Martin 離開核心團隊
近日，Linux 社群再次爆發關於是否在核心中使用 Rust 語言的激烈爭論。一些開發者試圖將 Rust 程式碼新增到 Linux 核心中，但遭到了一些核心維護人員的強烈反對。他們認為，在核心中引入多種語言會增加複雜性，帶來安全風險，並且不受歡迎。
贊成將 Rust 程式碼新增到 Linux 核心中的代表——Asahi Linux 首席開發者 Hector Martin 因為提交的程式碼屢屢被拒近日剛剛憤然離職。
Asahi Linux 是一個旨在為蘋果 Silicon 晶片（如 M1、M2 等）裝置提供 Linux 支援的專案。蘋果 Silicon 晶片（如 M1、M2）採用了與傳統 x86 架構完全不同的 ARM 架構，這導致 Linux 社群需要重新適配核心和驅動程式。
這個專案的目標就是將 Linux 移植到基於 ARM 架構的蘋果硬體上，使使用者能夠在這些裝置上執行 Linux 作業系統。Asahi Linux 專案由開發者 Hector Martin（又名 Marcan）領導，專注於為這些裝置提供完整的 Linux 支援，包括 GPU 加速、電源管理和其他硬體功能。
“Asahi”（朝日）在日語中意為“朝陽”或“早晨的太陽”，象徵著新的開始和希望。這個名字反映了該專案為蘋果 Silicon 裝置帶來 Linux 支援的創新性和開拓性。
這個專案一直由 Hector Martin 領導，但近日 Hector Martin 在社交媒體發文稱自己已經離開了 Asahi Linux 核心團隊。
2發生了什麼？
那麼，這背後到底發生了什麼？事情要從 Hector Martin 與核心維護者 Christoph Hellwig 發生的衝突說起。
而這場衝突似乎已經預埋已久。早在去年 9 月，微軟軟體工程師 Wedson Almeida Filho 就因不滿 Rust for Linux 專案中出現的“非技術性廢話”而選擇退出。他表示，與持有不同目標的人合作非常困難，這引發了人們對 Rust 在核心中應用前景的擔憂。
上個月，衝突再次升級。Linux 核心維護者 Christoph Hellwig 再次公開抵制一項允許 Rust 編寫的裝置驅動程式呼叫核心核心 DMA API 的提議。該補丁旨在允許 Rust 驅動程式使用 DMA API 的
dma_alloc_coherent() C 函式來分配和對映大記憶體區域以進行直接記憶體訪問。然而，Hellwig 堅決拒絕了該補丁。面對 Hellwig 的阻撓，Martin 敦促 Rust for Linux 團隊“在稽核並準備就緒後立即合併該系列，而不要理會 Christoph 公然破壞該專案的行為”。
Hellwig 在發給 Linux 核心郵件列表的郵件中寫道：“請不要在 kernel/dma 中使用 Rust 程式碼。”據我們瞭解，這個補丁將程式碼新增到了 Linux 原始碼樹的 rust/kernel，而不是 kernel/dma。
Rust for Linux 專案的 Miguel Ojeda 試圖緩和矛盾，他要求 Hellwig 提出替代方案，而不是一味地拒絕。
Hellwig 回覆說：“把包裝器留在你的程式碼裡，而不是給其他人添麻煩。”他還進一步指出，“DMA API 的介面應該保留在可讀的 C 程式碼中，而不是奇怪的繫結中，這樣才能保持它的可搜尋性和可維護性。”Hellwig 似乎希望非 C 語言驅動程式有自己的私有 C 程式碼繫結，並且這些抽象不應單獨維護，甚至不應在 rust/kernel 樹中維護。
紅帽軟體工程師 Danilo Krummrich 參與了 Rust for Linux 專案，他向 Hellwig 提出質疑，而 Hellwig 則明確表示他不想處理 Rust 程式碼。
他寫道：“別硬要我迎合那些當下時髦的程式語言。維護多語言專案是件痛苦的事。如果你想用 C 語言之外的東西，無論是組合語言還是 Rust，你得自己解決與 C 語言介面的相容性問題。”
對此，Krummrich 解釋說，Rust for Linux 專案正在開發 Rust 程式碼，抽象出供所有 Rust 驅動程式使用的 C 語言 API，並由 Rust 開發人員集中維護。換句話說，核心的 C 語言部分保持不變，而 Rust 驅動程式透過這些抽象來呼叫 C 程式碼，且這些抽象由 rust/kernel 團隊集中維護，這或許比每個驅動程式都有自己的獨立 C 語言繫結要好。
但 Hellwig 似乎不想單獨維護 DMA 的 Rust 抽象層。他解釋說，他不想再增加一個維護者：
“如果你打算因為跨語言程式碼庫而讓 Linux 變得難以維護，那就在你自己的驅動程式裡做吧，而不是把這種“癌症”傳播到核心子系統中。（這裡的‘癌症’是指跨語言程式碼庫，而不是 Rust 本身，只是為了避開那些喜歡煽風點火的人）。”
學技術歷史的人或許應該記得，2001 年，時任微軟執行長的 Steve Ballmer 曾將 Linux 比作癌症。Ballmer 當時說：“Linux 是一種癌症，它會在智慧財產權層面附著於它所接觸到的一切。”那時 Linux 還沒有發展到可以融入 Windows Subsystem for Linux。
Hellwig 繼續爭辯道，將 DMA 一致性分配器的 Rust 抽象層單獨交給其他人維護，並不能改善現狀，反而會削弱核心的可維護性：
“每增加一點其他語言的內容，都會極大地降低核心的可維護性。Linux 之所以能夠存活這麼久，是因為它沒有內部界限，而引入另一種語言則會完全破壞這一點。你可能不喜歡我的回答，但我會盡我所能阻止這種情況。這並不是因為我討厭 Rust。儘管它不是我最喜歡的程式語言，但肯定是最好的新語言之一，我鼓勵人們在適合的專案中使用它。我只是不希望它出現在我需要維護的龐大的 C 語言程式碼庫裡。”
面對 Hellwig 一再的強硬拒絕之詞，Ashai Linux 專案負責人 Hector Martin 坐不住了。Hector Martin 向外界公開表示，他認為 Hellwig 的言論違反了行為準則，但他懷疑是否會真的採取紀律處分。
Martin 認為，Rust for Linux 的開發人員應該忽略 Hellwig 的擔憂，並將補丁提交給核心負責人 Linus Torvalds 評審：
“如果 Linus 不在這個話題上發表權威意見，Miguel 和其他 Rust 團隊成員應該在補丁經過評審後直接合並，無視 Christoph 試圖破壞專案的企圖。如果 Linus 接受了這個拉取請求，Christoph 說什麼都不重要。如果 Linus 不接受，Rust for Linux 專案基本上就死了，除非 Linus 或 Christoph 採取下一步的行動。其他的都是在兜圈子。”
針對這一糾紛，外媒 The Register 曾詢問 Hellwig 是否願意就本文發表評論，他拒絕了。The Register還曾向 Linux 基金會研究員 Greg Kroah-Hartman 徵求意見，但他尚未回覆。
這次爭議再次暴露了 Linux 社群在 Rust 應用問題上的分歧。一部分開發者積極擁抱 Rust，認為它可以提高核心的安全性、效能和開發效率；而另一部分開發者則堅持使用 C 語言，對 Rust 持謹慎態度。
在這種分歧下，作為 Linux 社群的核心人員，Linus Torvalds 對於 Rust for Linux 的態度一直備受關注。偏偏，這位敢怒敢言的大佬也參與了 Hellwig 和 Martin 的這場紛爭中。
2 月 6 日，Linus 向 Martin 傳送了一封郵件，郵件中隱晦地指責了 Martin“煽動”網友情緒——在社交媒體上爭取支援。Linus 在郵件中寫道：
你能否接受這個事實：也許問題就出在你身上？ 你以為自己知道得更多。但當前的流程是有效的。 （流程）確實存在問題，但問題就是生活的事實。沒有完美的事物。 然而，我要說的是，社交媒體的攻擊讓我不想要和你的方法有任何瓜葛。 因為如果我們在核心開發模型中遇到問題，那麼社交媒體肯定不是解決方案。同樣，它肯定也不是政治分歧的解決方案。 技術補丁和討論很重要。社交媒體宣傳——婉拒了哈 謝謝。
看到 Linus 發來的郵件，Martin 也倍感委屈。
Martin 回覆郵件稱，之所以將這些爭論在網上公佈出來，是因為自己已經別無選擇。
如果在社交媒體上羞辱別人沒用，那告訴我什麼有用？ 因為我已經沒招了。 我真心希望技術補丁和討論能成為真正重要的東西，但我覺得我們在這方面遇到了困難，至少在核心開發過程的某些環節中是這樣。 沒有人會把這句話理解為支援在社交媒體上辱罵別人作為“解決方案”。
Martin 提到自己從 1991 年開始參與 Linux 開發，見證了 Linux 的成長，但現在他對一些現狀感到遺憾。他最近領導了一個旨在為 Linux 社群提供通用安全模型的倡議，但兩年內提交了四個補丁系列，卻沒有一行程式碼被審查過。儘管他們非常謹慎地提交程式碼，並嘗試參與技術討論，但幾乎沒有得到任何有意義的反饋或交流。
我是從 1991 年 12 月開始參與 Linux 開發的，對這個問題的看法也基於此。1995 年，我在麻省理工學院由 Stallman 贊助的自由軟體會議上第一次見到你（這裡指 Linus）和 Tove。當時我告訴你，北達科他州的癌症患者因為我們在 Linux 上的工作以及最佳化癌症中心的醫療流程，能夠享受更多與家人在一起的時光。
90 年代，RedHat 請我在多個會議上演講，談論 Linux 將如何主導企業計算，因為這是技術人員做“正確”技術的事情。
我現在看到的一些事情讓我後悔說了那些話。
可能我職業生涯的最後一項技術貢獻是領導一個為 Linux 社群提供通用安全模型架構的倡議。這不是要取代或替換當前正在做的任何事情，而是為了在這個機器學習和建模的時代，為開發和定製工作負載模型提供一個靈活的替代方案。
兩年內提交了四個補丁系列，截至昨天，沒有一行程式碼被審查過。
這個貢獻只涉及它自己的目錄，除非人們選擇在其控制下執行工作負載，否則它不會做任何事情。
我們在提交時非常小心，以免浪費維護者的時間。我們甚至等了兩個月，沒有任何訊息，才傳送了一封詢問其中一份提案狀態的郵件。我們被告知，相當簡短地說，如果我們曾經詢問過它們，我們傳送的任何東西都可能被忽略。
我們嘗試參與技術討論，可能是過度參與，試圖解釋我們為什麼以及如何選擇實施我們的提案。包括來自執行生產 IT 系統的顧問的意見，他們認為需要更好的方法來滿足他們的安全需求。
從來沒有進行過任何相關的技術交流。討論的內容是，我們已經決定以某種方式做事，沒有討論，如果你不喜歡，你真的應該考慮做一些其他事情，而不是提交給上游 Linux。
Martin 認為，當前的核心開發模式存在一些問題，尤其是缺乏對新思想的開放和尊重。雖然 Linux 是作業系統領域創新的重要平臺，但如果繼續忽視貢獻者的努力，可能會扼殺創新。他還提到，行為準則雖然存在，但在實際執行中似乎並沒有起到應有的作用。
如果大型科技公司能僱傭到“無所不知”的專家來擔任核心子系統的維護者，這種模型會很好用。但現實中，這樣的人非常稀缺。如果沒有足夠多的高水平維護者，創新可能會被扼殺，而 Linux 是作業系統領域唯一能真正推動創新的地方。
（但專案管理仍然存在一些問題。）從專案管理角度看，目前還沒有明確的解決方案。科技行業從未遇到過如此複雜的挑戰。傳統的開源“分叉”模式（即透過分叉專案來解決問題）在 Linux 這種規模的專案上行不通。
雖然已經有了行為準則（比如禁止辱罵和人身攻擊），但如果想有效推進專案，維護者們還需要一套更明確的行為標準。而這些，Jim，你聽見了嗎？
尊重他人和開放接納新思想是專案順利執行的潤滑劑。但遺憾的是，這種態度在科技行業中非常罕見，就像“無所不知”的專家一樣稀缺。
最後，Hector 向 Linus 及其家人致以祝福，並感嘆這段經歷讓他對行業現狀有了更深的思考。他希望未來能夠找到一種更有效的方式，讓技術討論和創新能夠順利進行。
2022 年 10 月 3 日，Linux 核心增加了對 Rust 程式碼的支援。此前不久，微軟 Azure 首席技術官 Mark Russinovich 曾主張新的程式設計專案應該用 Rust 而不是 C 或 C++ 來編寫。
Russinovich 說：“為了安全性和可靠性，行業應該宣佈這些語言已經過時。”
他的理由是，Rust 程式碼可以避免困擾 C 和 C++ 程式碼的記憶體安全漏洞（例如緩衝區溢位），而這些漏洞是大型專案中大多數嚴重漏洞的根源。這種觀點隨後得到了世界各地政府安全機構的支援。
C 和 C++ 開發者注意到人們對 Rust 興趣的增長，並承認需要解決記憶體安全問題。因此，目前有許多專案正在進行中，例如 TrapC、FilC、Mini-C 和 Safe C++，旨在增強 C 和 C++ 對記憶體漏洞的抵抗能力。此外還有 DARPA 的 TRACTOR 專案，目標是自動將 C 程式碼轉換為 Rust。
在 Filho 去年宣佈退出 Rust for Linux 專案後不久，Linux 負責人 Linus 在奧地利維也納的 Linux 基金會開源峰會上談到了 C 和 Rust 開發人員之間存在的摩擦。
Linus 說：“顯然，有些人就是不喜歡 Rust 這個概念，也不希望 Rust 進入他們的領域。甚至有人在談論 Rust 整合是一個失敗……我們已經做了兩年，現在說這個還為時過早，但我認為，即使它最終會失敗——但我不認為它會——這也是學習的一部分。”
到目前為止，Linux 開發者社群已經清楚地意識到，Rust 並不總是受歡迎的。
2 月 3 日，Hector Martin 要求移除其 Linux 維護者的身份。
他在發給 Linux 核心郵件列表的郵件中寫道：“我對核心開發流程或社群管理方式已經失去了信心。”
“蘋果 /ARM 平臺的開發將繼續在下游進行。如果我以後自己想為某個子程式碼樹提交一些補丁到上游，或許我會，或許不會。任何願意自己去爭取上游合併的人都可以去做。”
3網友怎麼看？
這次爭議不僅阻礙了 Rust 程式碼進入 Linux 核心的程序，也加劇了社群內部的對立情緒。Rust for Linux 專案的未來發展面臨諸多不確定性。
Martain 的離職在社交媒體上引發了激烈討論。在 Hacker News 上，有位使用者的對於該事件的評論獲得了諸多網友的贊同。
“簡單來說，Linus Torvalds 在處理 Rust 問題上表現得很猶豫，沒有明確表態支援或反對，導致 Linux 社群內部產生了信任危機。他的模糊態度讓問題變得更糟，尤其是他平時對 C++ 等技術的立場都很明確，但這次卻一反常態。
Rust-for-Linux（R4L）專案早就該有個明確的結果了，但經過幾年的開發，它的未來依然不明朗。Linus 沒有積極推動共識，反而坐視團隊內部爭吵，最後把責任推給了 Martin。這種做法讓人失望。
他對 Martin 的批評其實暗示了他對 Rust 的不看好，但他始終沒有公開明確表態。可能是因為他擔心會引起更大的爭議。不過，現在可能是他該直接表態的時候了。
如果 Linus 從一開始就果斷地說‘不’，很多時間和精力（尤其是 Martin 的）都可以省下來，這場鬧劇也能避免。”
甚至有人認為，Linus 對 Martin 的斥責已經表明了他對 Rust 的態度——可能永遠不會真正支援 Rust。
“Linus 對 Martin 的批評其實暗示了他對 Rust 的態度——他可能永遠不會真正支援 Rust。不過，這件事更多和 Hector 的行為有關，而不是 Rust 本身。Hector 威脅要透過社交媒體曝光別人，這種行為是非常不好的。
他只是一個長期貢獻者，可能有點粗魯，但並不是什麼十惡不赦的人。
另外，關於 Rust 的討論並不是簡單的“支援”或“反對”問題。沒人完全反對在核心的某些部分使用 Rust，但具體在哪些部分用、怎麼用、用在哪裡，這些才是大家爭論的焦點。Linus 對這類分歧一向比較放任，沒有強行推動共識。”
有人懷念 Hector 所做的貢獻，並認可他對於 Rust for Linux 未來悲慘狀況的預判。
“從旁觀者的角度來看，有時你需要有人站在你這邊，成為改變現狀的倡導者。我會懷念 Hector 的貢獻，並且認為他對 Linux 核心開發過程的悲慘狀況的判斷基本上是正確的。如果這個社群對變革更加開放，那麼像 Hector 這樣的人就能夠創新，而不會產生怨恨”
事實上，網友認為，作為 Linux 社群中最有話語權的關鍵人物，Linus 應該公開宣告不應該對 Rust for Linux 貢獻者進行攻擊。
“我認為他有義務公開宣告這種對 Rust for Linux 貢獻者的攻擊是不可接受的，並授權未來在類似情況下的補丁儘管收到 NACK 但仍繼續前進，特別是考慮到補丁作者已在郵件列表中明確尋求他和 GKH 的處理方式。”
儘管 Rust for Linux 團隊在技術上取得了顯著進展，但如何與核心維護者達成共識仍是該專案面臨的最大挑戰。隨著爭論的持續，Linux 社群將不得不權衡 Rust 帶來的潛在好處與維護多語言核心的複雜性。這場爭論的結果可能會對 Linux 核心的未來發展產生深遠影響。
參考連結：
https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux
https://www.reddit.com/r/rust/comments/1iju93d/asahi_linux_lead_developer_hector_martin_resigns/
https://news.ycombinator.com/item?id=42972062
https://lore.kernel.org/rust-for-linux/[email protected]/
https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/
– EOF –
關注「程式設計師的那些事」加星標，不錯過圈內事
點贊和在看就是最大的支援
