整理 | 屠敏 出品 | CSDN（ID：CSDNnews）
自 Linux 核心長期以來由 C 語言構建起步，直到 Rust 這股新興力量悄然湧入，程式語言之爭這把“火”，現如今不僅“燒”到了全球主流開源作業系統 Linux 的中心，還將 Linux 原有的維護者與 Rust 開發者推向了前所未有的對立面。
在一些 Rust 開發者看來，Rust 是安全語言的象徵，在 Linux 核心中引入此語言無疑可以提高系統的效能、安全性。
然而，這一說法並未得到 Linux 核心維護者的認可，他們反而擔心，多種語言的使用會讓這個超級開源專案的維護變得更加困難，其甚至直言——Rust 與 C 語言的混合程式碼在 Linux 中就是“癌症”。
爭論之下，Linux 之父 Linus 出面回應、核心開發者憤而辭職選擇從此視而不見聽而不聞…
Linux 核心維護者 vs Rust 開發者的口舌之爭
其實 Rust for Linux 專案推進起來已有幾年的時間，此前在 Linux 6.13 核心的“char/misc”模組合併中，新增了對 Rust 的支援，使得開發者能夠使用 Rust 編寫 misc 驅動程式，這是一些良好的開端。
不過，期間也出過一些“意外”，如去年 9 月，微軟軟體工程師也是 Rust for Linux 的核心維護者 Wedson Almeida Filho 官宣自己退出 Rust for Linux 這一專案，給出的理由是——已經疲於應對社群內越來越多與技術毫無關係的“廢話”了，但好在此後專案仍在持續推進。
至於此次如文章伊始所述的 Linux 核心維護者和 Rust 開發者公然“互懟”又是為哪般？
具體看來，還是因為一場技術爭議引發的口舌之爭。
就在上個月，有人在 Linux 核心中帶來了一個提案——想讓用 Rust 寫的裝置驅動能夠呼叫 Linux 核心中用 C 寫的一個重要功能（DMA）。
具體來說，在 Linux 系統中，裝置（比如網絡卡、顯示卡等）有時需要直接訪問計算機的記憶體，而不經過 CPU 的干預。這種方式叫做直接記憶體訪問（DMA, Direct Memory Access）。為了讓裝置能夠使用 DMA，作業系統需要做兩件事：
-
分配一塊記憶體：這塊記憶體是裝置可以直接訪問的。
-
對映這塊記憶體：告訴裝置這塊記憶體的物理地址，這樣裝置才知道去哪裡讀寫資料。
在 Linux 核心中，有一個專門的 API 叫做 DMA API，它提供了一些函式來幫助完成這些任務。其中一個重要的函式是 dma_alloc_coherent()，它的作用是：
-
分配一塊記憶體，並且保證這塊記憶體是“連續的”（裝置通常需要連續的記憶體塊）。
-
同時，它會把這塊記憶體的物理地址對映給裝置，這樣裝置就可以直接訪問這塊記憶體了。
基於此，有人在 Linux 核心中提交了一個補丁，目的是讓 Rust 編寫的驅動程式也能使用這個 dma_alloc_coherent() 函式，這樣 Rust 驅動程式也能像 C 語言編寫的驅動程式一樣，使用 Linux 核心提供的 DMA 功能，從而更高效地處理裝置與記憶體之間的資料傳輸。
然而，這個提議遭到了 Linux 核心維護者 Christoph Hellwig 的強烈反對。Hellwig 明確表示，他不希望在核心的 DMA 部分看到 Rust 程式碼。
實際上，這個補丁只是將程式碼新增到了一個不同的地方（rust/kernel），而不是直接改動 DMA （kernel/dma）部分。
Hellwig 的拒絕讓很多 Rust 開發者們感到鬱悶，對此，Rust for Linux 專案的首席開發者 Miguel Ojeda 出面請求 Hellwig 給出一個替代方案。
Hellwig 回應道：“把包裝器放在你們自己的程式碼裡，而不是讓別人為你們的事情受苦。”
因為是在郵件列表的回應，所有開發者都可以看到，對此，Red Hat 的軟體工程師 Danilo Krummrich 直接質問 Hellwig，「你們自己的程式碼是什麼意思？是不是在每個驅動程式中都重複了？否則，rust/kernel/dma.rs 看起來合理，對吧？」
Hellwig 接著表示：“DMA API 的介面應該保持在可讀的 C 程式碼中，而不是用奇怪的繫結來實現，這樣它才可以被 grep 搜尋並且更易於維護。”
此外，Hellwig 也明確表示他根本不願意處理 Rust 程式碼。他寫道：“不要強迫我處理你們這門時髦的語言。維護多語言的專案很痛苦，我沒有興趣去處理。如果你們想用的不是 C 語言，像組合語言或 Rust，你們自己寫 C 介面，自己解決語言不匹配的問題，反正我不管。”
Red Hat 的軟體工程師 Danilo Krummrich 解釋稱，並沒有人要求你處理或者維護這段 Rust 程式碼。Rust for Linux 專案正在建立 Rust 程式碼，它將 C API 抽象化，供所有 Rust 驅動程式使用，並由 Rust 開發者來維護。
換句話說，核心中的 C 程式碼保持不變，而 Rust 驅動程式透過抽象層來使用這些 C 程式碼，這些抽象層由 rust/kernel 中的團隊集中維護，整體上比每個驅動程式自己編寫 C 語言繫結要好。
但 Hellwig 似乎不願意讓 DMA 的 Rust 抽象層單獨維護，甚至不應該在 Linux 原始碼樹 rust/kernel 中維護。他怒斥道：
“如果你們想讓 Linux 因為跨語言的程式碼庫變得無法維護，那就讓你們的驅動自己去做吧，而不是把這種‘癌症’傳播到核心子系統中。（這裡說的‘癌症’顯然是指跨語言的程式碼庫，而不是 Rust 本身，只是為了避免被激起爭議）”
此話一說，這讓人想起 2001 年，前微軟 CEO 史蒂夫·鮑爾默曾將 Linux 比作癌症。他當時說：“Linux 就像一種癌症，它會在智慧財產權的層面附著到它接觸的每一個東西。”那時 Linux 還沒有擴充套件到 Windows 子系統中。而現如今 Windows 開始深度整合 Linux 子系統，微軟深度擁抱了開源。
Hellwig 繼續論述說，讓其他人單獨維護 Rust 的抽象層來處理 DMA 的記憶體分配器，並不會改善問題，反而會妨礙核心的可維護性：
“每引入一種新語言，就會大大降低核心作為一個整體專案的可維護性。Linux 之所以能生存這麼久，是因為它沒有內部邊界，而引入另一種語言完全破壞了這一點。你可能不喜歡我這麼說，但我會盡全力阻止這種做法。這不是因為我討厭Rust。雖然它不是我最喜歡的語言，但它絕對是新興語言中最好的之一，我鼓勵人們在適合的情況下用於新專案。我只是不希望它出現在我需要維護的大型 C 語言程式碼庫中。”
幾輪辯論之後，Red Hat 的軟體工程師 Danilo Krummrich 認為：
Hellwig 作為一名維護者，他的一些舉措超出了維護者的工作範圍，即：
根據個人喜好，任意限制某個實體對公共核心 API 的使用。
為此，他和 Asahi Linux 專案負責人 Hector Martin 紛紛請求 Linux 之父 Linus Torvalds 出面解決這一問題。
Asahi Linux 專案負責人 Hector Martin 在郵件中寫道：
我的看法：如果 Linus 沒有在這個討論中給出權威的答覆，Miguel 和其他 Rust 的開發者應該在程式碼經過審查並準備好後，直接合並這部分內容，不必理會 Christoph Hellwig 明顯想要破壞專案的行為。
如果 Linus 拒絕合併，那麼 Christoph 說的就無關緊要了。
如果 Linus 不合並，R4L 專案基本上就會死掉，除非 Linus 或 Christoph 採取行動。其他的討論只是繞圈子。
Rust 開發者們：請不要浪費時間和精力去糾結這種戲劇性的事情，這不值得。要麼 Linus 喜歡，要麼他不喜歡。其他的都是少數破壞者維護者故意製造的干擾，他們想透過打擊你們計程車氣來讓你們放棄，因為他們知道自己終究會在歷史中處於失敗的一方。舊的固守陣地的維護者再怎麼破壞，也無法阻止世界向記憶體安全語言的方向發展。
順便說一句，我認為 Christoph 的“癌症”言論足以成為違反行為規範的理由，但我懷疑不會有任何相應的處理。
Linus 回懟：我根本不想參與你的社交媒體輿論戰
殊不知，Hector Martin 的這一則郵件直接將 Linus 推到需要做出二選一決策的”邊緣“。
面對 Hector Martin 呼籲 Linus “發表權威回答”以解決裝置驅動的僵局，並支援透過“社交媒體羞辱”來反擊 Linux 維護者對 Rust 程式碼的敵視，Linus 對此方法予以否定。
Linus 極其禮貌但毫不客氣地回應 Martin：
如果在社交媒體上羞辱他人沒有效果，那就告訴我，還有什麼方法有效，因為我已經沒有其他辦法了。
你能不能接受一個事實，也許問題出在你自己身上？
你以為你知道得更好，但目前的流程是有效的。
它有問題，但問題是生活的一部分。沒有完美的東西。
不過，我必須說，社交媒體的“圍攻”讓我根本不想再和你們的做法有任何關係。
因為如果我們在核心開發模式中有問題，那麼社交媒體絕對不是解決方案。就像它根本不是政治問題的解決方案一樣。
技術補丁和討論才是關鍵。社交媒體圍攻——謝謝，但不需要。
Asahi Linux 首席開發者 Hector Martin 辭去上游 Apple Sillicon 維護者職務
在得到 Linus 的回覆之後，Hector Martin 憤而決定辭去 Apple Silicon 程式碼的上游維護者職務。
Hector Martin 在最新的一次補丁中寫道：
“我已經不再對核心開發過程或社群管理方式抱有任何信心。
Apple/ARM 平臺的開發將繼續在下游進行。如果未來我有興趣向上遊提交一些補丁，不管是針對哪個子樹，我可能會，也可能不會。任何願意自己為上游提交做出努力的人都可以去做。”
Hector Martin 看起來似乎不打算再直接為上游 Linux核心貢獻程式碼，而是隻專注於 Asahi Linux 的下游程式碼。
相信使用 macOS 系統的開發者對於 Asahi Linux 這個專案也並不陌生，它是一個旨在將 Linux 移植到搭載 Apple Sillicon 晶片上 Mac 的計劃，使蘋果的系統可以執行 macOS 以外的作業系統。
現下隨著 Hector Martin 辭職，其他人可能會接手處理補丁，以努力將其提交到上游。Asahi Linux 的開發者兼共同維護者 Sven Peter 聽聞這一訊息後出面表示：“給我幾天時間來弄清楚我們該怎麼做。我認為我們可以繼續推動該樹的前進。”
但無論如何，這些關於上游 Linux 核心郵件列表的爭論並不利於推動 Apple Silicon 的支援，尤其是對於那些希望在 Apple Mac 上看到 Linux 的使用者，而不僅僅是在 Asahi Linux 的框架下。
Linux 中的 Rust、C 之爭依然在持續
社群的動盪必定會影響到技術的穩定發展。回看 Linux 核心自 2022 年開始整合 Rust 程式碼，但它仍然是一個以 C 為主的程式碼庫。許多 C 語言程式設計師明確表示，他們不會因為 Rust 的崛起而改變自己的方式。而 Rust 的忠實使用者則認為，Rust 程式碼可以避免 C 和 C++ 中常見的記憶體安全問題（如緩衝區溢位），這些問題構成了大部分大規模專案中的嚴重漏洞。
在引入 Rust 的過程中，C 和 Rust 開發者之間的摩擦也是不可避免的，Linux 的創始人 Linus Torvalds 也對此有深刻認識，他曾在 Linux 基金會的開放原始碼峰會上提到過這一點。
Torvalds 說：“顯然，有些人就是不喜歡 Rust，也不希望 Rust 侵犯他們的領域。有人甚至在說 Rust 的整合是失敗的……我們做這個已經好幾年了，現在說失敗還太早，但即使它最終失敗了——雖然我不認為會失敗——那也是一種學習的方式。”
此外，他還指出，目前核心中的任何功能都不依賴 Rust，短期內也不會依賴。重要的是向前推進，因此開發者們應該“全速前進”，暫時不要太在意這些問題。即便現在細節還不完善，只要能讓功能正常執行就足夠了。一旦使用者開始依賴 Rust 程式碼，才需要更細緻地處理這些問題。但現在，如果開發者因為過於謹慎而裹足不前，反而會讓專案受挫。
只是在此次爭論中，Linus 的處理方式讓不少開發者覺得有些不滿：
Rust 問題暴露了 Torvalds 作為領導者的一次罕見失職。與其果斷地說“不是，絕對不行”或者“是的，執行”，他在 Rust 的問題上一直模稜兩可。鑑於 Linux 社群中有相當一部分（且非常 vocal）的人對他的決定產生了信任危機，這種猶豫不決的態度反而起到了適得其反的效果。而且 Linus 沒有明確立場，實在是有些反常（比如我們都知道他對 C++ 的立場）。
作為一個試點專案，R4L 應該早就畢業或者結束了。但經過多年積極開發，它的現狀依舊不明朗。Linus 並沒有採取措施讓大家達成共識，而是選擇一直坐視不管，看著下屬們相互爭鬥，最後還將責任推給 Martin，實在是欠妥。
可以說，他對 Martin 的訓斥明顯表明了他永遠不會偏袒 Rust，但他並沒有明確說出來。也許他知道應該表態，但又擔心會引發一場風暴。也許現在是時候撕掉創可貼了。
再說一次，所有這些本來都可以避免，如果他當初能堅定地站隊，不論是贊成還是反對。想象一下，如果 Linus 直接說“不要，保持在下游”，能節省多少時間和精力，甚至是僅僅 Martin 的時間。
對此，你怎麼看？
來源：
https://news.ycombinator.com/item?id=42972062
https://www.phoronix.com/news/Asahi-Linux-Lead-No-Upstream
https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/
https://lore.kernel.org/lkml/Z5qeoqRZKjiR1YAD@pollux/
官方站點：www.linuxprobe.com
Linux命令大全：www.linuxcool.com
劉遄老師QQ：5604215
Linux技術交流群：2636170
（新群，火熱加群中……）
想要學習Linux系統的讀者可以點選"閱讀原文"按鈕來了解書籍《Linux就該這麼學》，同時也非常適合專業的運維人員閱讀，成為輔助您工作的高價值工具書！
