Linux 內核開發者對 Rust 進入內核的討論

Rust for Linux 這個項目是希望今後可以使用 Rust 編程語言來編寫內核代碼，該項目已經進行了幾年，有越來越多的開發者認為是時候將這項工作合併到主線中了。在 2022 年的 Linux 內核維護者峰會上，Miguel Ojeda 向大家更新了此項目的最新狀況，希望能達成一致來確定何時可以完成合併。

他得到的答案是很清晰的：內核中確實很快會有 Rust 了。

這方面並沒有什麼懸念。Linus Torvalds 在會議開始時就說，他計劃接受（可能在 12 月中旬發布的） 6.1 內核的 Rust 補丁，除非他聽到強烈的反對意見。Ojeda 表示，他很期待這一天，並詢問這些補丁應該如何進入主線。Torvalds 說，他不願意直接接受這些補丁，所以看起來很可能需要 Kees Cook 來將這項工作引向上游。

Dave Airlie 說，有一些 MacBook 驅動程序的開發者打算用 Rust 來做他們的工作，所以很可能在不久之後就會有真正的 Rust 驅動程序進入上遊了。不過，Torvalds 說他希望最開始只合入盡量少的內容，只是讓基礎設施先進入內核，讓開發者開始使用它。它應該可以完成編譯，但應該基本僅限在 「hello, world」 這種水平就好。他說，這將是一個向世界發出的信號：「終於落地了」。

Greg Kroah-Hartman 問道，針對特定子系統的 Rust 綁定實現，該如何進入上游；是應該通過 Rust 樹還是通過相關子系統的維護者？Ojeda 回答說，Rust 核心支持應該通過 Rust 樹來合入，但其他的應該經過維護者來合入。Alexei Starovoitov 擔心，如果子系統維護者不想在他們的子系統中使用 Rust，他們也無法拒絕 Rust 補丁；James Bottomley 補充說，對於長期從事 C 語言開發的人來說，Rust 可能是一種很難理解的語言，把它強加給維護者並不合適。Torvalds 回答說，這應該由維護者決定；目前沒有必要制定統一的規則。

Paolo Bonzini 說，對於不熟悉該語言的開發者來說，針對特定子系統實現抽象層的 Rust 代碼往往是最難讀懂的，「but it's stupid code」，並沒有做什麼複雜的動作。驅動程序級的 Rust 代碼則要簡單易懂得多。Torvalds 重申，就目前而言，維護者將可以說他們不想接受 Rust。但 Starovoitov 反駁說，無論他如何決定，BPF 都會受到影響；開發者需要能夠對 Rust 代碼進行跟蹤 來調試問題。他補充說，每個人最終都會需要了解 Rust。Torvalds 回答說，他預計這個過程需要幾年時間。

Cook 說，這種變化將類似於內核所經歷的許多 C 語言變動。停止使用可變長度數組也是一個類似的過程，開發人員目前已經習慣了這一點。Torvalds 說，這其實更加類似於 BPF 的引入過程；這也是一種新的語言，起初是針對特定使用場景的，但現在已經無處不在了。

Ted Ts'o 指出，內核必須使用不穩定的 Rust 功能，這就導致不好確定應該使用 Rust 的哪個版本了。也許開發者應該宣布一個特定版本的編譯器作為內核開發所使用的版本？這將鼓勵發行版提供商把這個版本打包發行出來，使其得以更廣泛地被採用。Thomas Gleixner 說，在 kernel.org 上提供我們選定的編譯器應該就夠了，但 Torvalds 回答說，只要有可能，他都希望優先從發行版提供商那裡獲取編譯器。Bottomley 問道，Rust 什麼時候會成為內核編譯的必備條件；答案是 「當某人需要使用的硬體需要 Rust 的時候」。Torvalds 說，如果這一天到來了，那說明 Rust 在內核開發領域是非常成功的了。

Gleixner 問 Rust 語言現在的規範性如何；Ojeda 回答說，這取決於人們希望用什麼。Rust 保證了穩定功能都可以向後兼容，所以這些功能不會意外不能用了。不過，內核正在使用一些不穩定的功能；這些功能出現變動是很有可能的。目前正在做的工作就是把這些功能穩定下來，以便讓內核能夠穩定地使用它們。

目前正在努力為 Rust 編寫一個強調安全的系統的規範，這會最終得到一個類似於標準的文檔。不過 Ojeda 說目前基於 GCC 的 gccrs Rust 編譯器的開發者發現當前的文檔有些地方比較模糊。其中經常把相關行為定義為 「參考 rustc 編譯器的實現方式」。他說，這 「不是好事」，但會繼續改善。

Gleixner 還詢問了生成 Rust 綁定的工具，尤其是有沒有自動化工具來確保 Rust 和 C 版本的數據結構是相互匹配的。Ojeda 說，這些工具確實存在，但它們還不能成功地對所有類型完成自動轉換。這也是可以解決的。

最後，Gleixner 告誡 Rust 開發者不要改變 C 語言中鎖定原語的語義；目前看來大家也沒有表現出這樣的傾向。Ts'o 補充說，應該從一開始就讓 Rust 的鎖定抽象能跟 lockdep 這個鎖定檢查工具配合起來。Chris Mason 插話說，如果 Rust 代碼需要 lockdep，這將是該語言成功的另一個標誌，是時候 「跳個舞慶祝勝利」 了。

人們經常說，將 Rust 合併到內核代碼樹中還是一個實驗性質的動作；如果不成功就可以刪除掉。Ojeda 說，為 Rust for Linux 工作的開發者們想知道試驗期可能會有多長。不過，他並沒有從這個小組討論中得到切實的答案。

相反，Bottomley 建議說，與其引入 Rust，不如直接將更多類似 Rust 的功能移入 C 語言。Ojeda 說，他實際上一直在與 C 語言委員會合作來推動這些改進，但這方面的任何變動如果能夠落實，也需要很長的時間。Christoph Hellwig 說，除非計劃用 Rust 重寫整個內核，否則這種改動無論如何都得去做；他對使用一種新的語言來重寫已經能正常工作的代碼的方案不是很滿意。他說，也許 sparse 靜態分析工具可以加強一下，從而實現更多 Rust 可以做到的檢查。Ojeda 回答說，這種做法最終的效果就像是又獲得了一個 Rust 一樣——但時間上要晚很多。

Hellwig 繼續說，可以隨著時間的推移，來逐步採用類似 Rust 的一些功能。這 「必定是不如從 Rust 開始」，但內核社區現在有一個龐大的代碼庫需要管理。他說，需要有一種方法將類似 Rust 的語言的好處納入所有的 C 代碼中。Cook 說他一直在推動編譯器開發人員來創建更安全的 C 語言。

Ts'o 在會議結束時指出，語言設計本身就是一個耗時很長的研究項目；也許我們大家應該在下一年來專註於策略問題。Torvalds 說，他希望看到各位維護者能運行一些持續集成測試並且加入 Rust 相關的測試——這個情況其實已經在進行中了。Laurent Pinchart 說，Rust 開發者需要準備好前期需要給內核社區提供支持；開發者會很快掌握一些技能，在一段時間後應該可以開始相互幫助了。Torvalds 補充說，Rust 其實並不是那麼可怕的；「畢竟不是 Perl」。

當被問及文檔問題時，Ojeda 說，Rust 的開發者正試圖改進一些相應的 C 語言中已經完成了的文檔。例如，可以讓 Rust 的文檔機制能很簡單地就確保這些例子是可以被實際測試通過的。他們正在遵守關於應如何解釋不安全區塊的規則。

時間不夠了，Matthew Wilcox 最後問道，內核開發人員是否應該編寫地道的 Rust 代碼，還是說應該寫 「C in Rust」。Ojeda 回答說，這些代碼在開始時可能更像 C 語言；採用更高級的功能（如 async）可能會需要更長時間。Gleixner 問，怎樣才能防止開發者使用那些不穩定的特性（是說等內核使用的特性已經變成穩定特性之後）；答案是指定內核開發時使用的編譯器版本。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive