LWN: Linux kernel 中的Rust！
關(guān)注了就能看到更多這么棒的文章哦～
The Rust for Linux project
By Jonathan Corbet
September 16, 2021
Kangrejos
DeepL assisted translation
https://lwn.net/Articles/869145/
首屆 Rust for Linux 會(huì)議，又名 Kangrejos，于 9 月 13 日正式開始了。組織者 Miguel Ojeda 在開幕演講上概述了為什么希望在內(nèi)核中使用 Rust、這里有哪些挑戰(zhàn)、以及目前的狀況如何。講座以及后續(xù)討論很好地概述了推動(dòng)這一倡議的原因，以及可能存在的一些癥結(jié)。
Why Rust？
他說，今年是 Linux 內(nèi)核誕生 30 周年，但同時(shí)也是 C 語(yǔ)言的第一個(gè) ISO 標(biāo)準(zhǔn)誕生 30 周年。C語(yǔ)言歷史悠久，也有很多負(fù)擔(dān)，但它仍然深度參與著如今的開發(fā)工作、并且也是很有意思的。Ojeda 說，他正在與 C 語(yǔ)言委員會(huì)合作來改進(jìn)該語(yǔ)言，但就算它能取得成果的話，這一過程也需要很長(zhǎng)的時(shí)間。
C 語(yǔ)言用于內(nèi)核開發(fā)的原因很多。它速度快，便于編寫底層代碼，簡(jiǎn)單，而且很適合 Linux kernel 這個(gè)環(huán)境。但是有一個(gè)小問題，就是有一些通常被人們稱為 "undefined behavior" 的行為。Rust 的優(yōu)勢(shì)在于它消除了這類 undefined behavior，至少在 "safe" 代碼中是這樣的。事實(shí)上，Rust 開發(fā)者所說的 "safe" 的意思，就是指它消除了這些未明確定義情況下的行為，而跟 "safety-critical" 這類術(shù)語(yǔ)完全沒有關(guān)系。根據(jù)這個(gè)定義來說的話，C語(yǔ)言中的 abort() 調(diào)用就是 safe 的，即使最后的結(jié)果是殺掉了一個(gè)進(jìn)程。Ojeda 為 C 語(yǔ)言提出了一個(gè) "[ [safty] ]" 屬性，希望用它來標(biāo)記所有那些需要避免 undefined behavior 的函數(shù)（并讓編譯器來強(qiáng)制保證這一點(diǎn)），但該提議沒有取得多少進(jìn)展。
那么按照 Rust 的標(biāo)準(zhǔn)，什么是不 "safe" 的呢？not-safe 行為的清單包括：在指針被釋放后使用指針、訪問 NULL 指針、兩次釋放一塊內(nèi)存、使用未初始化內(nèi)存中的內(nèi)容、內(nèi)存訪問越界、數(shù)據(jù)競(jìng)態(tài)行為（data race）等等。他斷言，這些事情在 Rust 代碼的 safe 部分都不會(huì)發(fā)生。這就是為什么他希望在內(nèi)核中能使用 Rust 代碼。他說，大約 70% 的 C 語(yǔ)言漏洞是由這些 undefined behavior 而導(dǎo)致的，而安卓多媒體和藍(lán)牙組件中的漏洞中接近 90% 都是這類問題。Rust 就可以幫得上忙了。Rust 還提供了許多其他優(yōu)勢(shì)，包括更嚴(yán)格的 type 類型、module 模塊、模式匹配原語(yǔ)、lifetime、一套完整的開發(fā)工具等等。
在內(nèi)核中使用 Rust 的壞處是什么？他說，不可能對(duì)所有的東西都完成建模，所以還是有必要使用一些不安全的代碼的。Rust 語(yǔ)言比 C 語(yǔ)言要復(fù)雜得多，其額外的 run-time check 會(huì)導(dǎo)致性能損失。當(dāng)然，對(duì)于內(nèi)核開發(fā)者和維護(hù)者來說，這又是一種需要學(xué)習(xí)的語(yǔ)言，這也是一個(gè)很大的成本。他說這是一個(gè)一次性的成本，會(huì)有很多回報(bào)，但這仍然得是要花精力的。Rust for Linux 的開發(fā)者們很樂意幫助開發(fā)者們來克服這個(gè)最初的學(xué)習(xí)障礙。
那么，作為一種系統(tǒng)編程語(yǔ)言，Rust 與 C 相比起來怎么樣？和 C 語(yǔ)言一樣，它的速度很快。它和 C 語(yǔ)言一樣可以開發(fā)底層代碼，但根據(jù)具體代碼的情況可能有些不一樣，開發(fā)者也許對(duì)有些代碼不容易預(yù)測(cè)其所產(chǎn)生的匯編代碼是什么樣子的。Rust 絕對(duì)不像 C 那么簡(jiǎn)單。他認(rèn)為，Rust 和 C 一樣都適合這個(gè)領(lǐng)域，但其他人可能會(huì)有其他看法。
Rust support in the kernel
到目前為止，Rust 支持了五個(gè)體系架構(gòu)：armv6、arm64、powerpc、riscv 和 x86-64。目前為止做這些工作的目的并不是要去支持所有架構(gòu)，那會(huì)帶來很多底層工作，而不一定能帶來什么新的好處。相反，我們的目的是要證明 Rust 是可以支持各種架構(gòu)的。目前有三個(gè)項(xiàng)目正在為內(nèi)核編譯 Rust 代碼。其中兩個(gè)使用了 "官方" 的 rustc 前端，然后使用 LLVM 或 GCC 來生成代碼。rustc/LLVM 的組合是目前領(lǐng)先的 Rust 編譯器方案。Ojeda 沒有對(duì) rustc/GCC 的搭配介紹。第三個(gè)項(xiàng)目正在為 GCC 開發(fā) native Rust 編譯器（gccrs），預(yù)計(jì)將在一兩年內(nèi)完成。
Rust for Linux 的工作分為 Rust 和內(nèi)核兩部分代碼 tree。Rust 這一邊有兩個(gè) crates，分別是 core（底層功能）和 alloc（數(shù)據(jù)結(jié)構(gòu)等）。alloc crate 也是之前試圖提交到內(nèi)核里面的一部分代碼，最終可能并不需要。這些 crate 被認(rèn)為是 Rust 庫(kù)的一部分，而不是內(nèi)核的一部分。
在內(nèi)核這一邊有 kernel 和 builtins crates。kernel crate 抽象了跟內(nèi)核其他部分的接口。利用了 bindgen 工具來生成 binding，從而允許從 Rust 調(diào)用內(nèi)核函數(shù)。目前看來還沒有需要從 C 語(yǔ)言調(diào)用到 Rust 的情況。他認(rèn)為有一個(gè)問題仍然需要完整的解決方案，那就是如何保持 C 語(yǔ)言和 Rust 兩邊同步。也就是要讓 Rust 成為內(nèi)核中的一等公民，如果開發(fā)者做了一個(gè)導(dǎo)致 Rust 代碼被破壞的改動(dòng)，那么他們就得負(fù)責(zé) fix 這個(gè)問題，也就是跟內(nèi)核的 C 代碼待遇要一樣。不過，目前還不清楚如何能達(dá)到這個(gè)效果。
驅(qū)動(dòng)程序作者的觀點(diǎn)就很有趣了。他們希望能為驅(qū)動(dòng)通常需要調(diào)用的所有內(nèi)核函數(shù)都創(chuàng)建好 Rust binding，打通這一使用場(chǎng)景，但 Rust-on-Linux 開發(fā)者的計(jì)劃不是這樣的。相反，他介紹說他們正在擴(kuò)充 kernel crate 來添加針對(duì)一些子系統(tǒng)的抽象層以及接口，希望能在編寫驅(qū)動(dòng)程序時(shí)不再有任何不 safe 的代碼。
Discussion
此時(shí)有些人提出了自己的擔(dān)憂，認(rèn)為這會(huì)要求維護(hù)者需要學(xué)習(xí) Rust。Ojeda 承認(rèn)這確實(shí)會(huì)是有必要的。最終維護(hù)者總是需要能夠?qū)λ麄兊淖酉到y(tǒng)負(fù)責(zé)的，盡管 Rust 開發(fā)者最初會(huì)幫助他們。Laurent Pinchart 說，可能需要很長(zhǎng)一段時(shí)間的幫助，他沒有辦法找到時(shí)間能停下手頭的工作來學(xué)習(xí) Rust，所以他將很難對(duì)他的子系統(tǒng)中的 Rust 代碼負(fù)責(zé)。
Ojeda 回答說，Rust 的開發(fā)者已經(jīng)意識(shí)到了這一點(diǎn)，他們一直在著重挑選那些有時(shí)間和興趣接受這一挑戰(zhàn)的維護(hù)者的子系統(tǒng)來作為開始。希望這樣能創(chuàng)造出足夠的例子和經(jīng)驗(yàn)來對(duì)今后引入其他子系統(tǒng)提供幫助。但他重申，維護(hù)者需要加入進(jìn)來。如果 Rust 不是內(nèi)核中的一等公民，那么這個(gè)實(shí)驗(yàn)就不會(huì)成功。他還說，早一點(diǎn)加入 Rust 的維護(hù)者可能會(huì)比晚一點(diǎn)加入的維護(hù)者能得到更多的幫助，這也是半開玩笑的說法。
Ojeda 說，雖然子系統(tǒng)維護(hù)者可能會(huì)增加一些困難，但對(duì)于驅(qū)動(dòng)程序開發(fā)者來說生活會(huì)更加容易，他們只需要使用提供給他們的（safe）接口就好。Pinchart 反對(duì)說，驅(qū)動(dòng)程序編寫者經(jīng)常發(fā)現(xiàn)他們需要對(duì)核心子系統(tǒng)進(jìn)行修改，這樣才能正確支持他們的設(shè)備，所以生活并不是想象的那么簡(jiǎn)單。他說，如果對(duì)驅(qū)動(dòng)程序作者的要求提高到需要精通 Rust，這將會(huì)真正阻礙一些人參與進(jìn)來。
Paolo Bonzini 擔(dān)心 Rust 代碼會(huì)抑制 internal kernel API 的改動(dòng)。開發(fā)者可能會(huì)發(fā)現(xiàn) Rust 代碼是某個(gè) API 的唯一使用者了，但此時(shí)可能會(huì)懶的修復(fù)這部分代碼（或者也是沒有能力去做這個(gè)），所以舊 API 就將繼續(xù)存在。他問道：Rust 開發(fā)者打算為核心內(nèi)核 API 增加多少個(gè) wrapper？例如，如果 file_operations 結(jié)構(gòu)中只有一些成員變量在 Rust 代碼中使用到了，那么是否還會(huì)對(duì)所有成員變量都生成 binding？如果增加了不必要的 binding 的話可能會(huì)導(dǎo)致將來改變這些 operation 的時(shí)候變得更加困難。Ojeda 回答說，對(duì)于像 file_operations 這么核心的東西，他們可能會(huì)把所有成員變量都加進(jìn)去，因?yàn)樽罱K總是都會(huì)被使用的。其他情況下，只會(huì)實(shí)現(xiàn) Rust 代碼實(shí)際使用到的接口。
討論接下來來到了工具鏈（toolchain），Ojeda 說，Linux 的 Rust 開發(fā)者目前只支持某一個(gè)特定版本的 Rust 編譯器來編譯任何一個(gè)內(nèi)核版本。其他版本的編譯器可能可以用，但不能保證。最終將有可能只會(huì)使用穩(wěn)定的 Rust 特性來編譯內(nèi)核，那時(shí)就有可能支持更多的編譯器版本了。他補(bǔ)充說，有人對(duì) Rust 語(yǔ)言的總體穩(wěn)定性表示擔(dān)憂，但他認(rèn)為這不是一個(gè)問題。這個(gè)語(yǔ)言現(xiàn)在很穩(wěn)定，而且變得越來越穩(wěn)定。現(xiàn)在編寫的內(nèi)核代碼，即使是使用不穩(wěn)定功能的代碼，"大部分" 在今后也都可以繼續(xù)使用。
正在開發(fā) gccrs 的 Philip Herron 問道：Linux 的 Rust 開發(fā)者特別希望看到用 Rust 編寫哪些部分的代碼？Ojeda 的觀點(diǎn)是文件系統(tǒng)以及其他一些包含大量狀態(tài)的子系統(tǒng)將是很好的選擇。Herron 接著問到，是否有計(jì)劃挑選 Rust 語(yǔ)言的一個(gè)特定子集來用在內(nèi)核中。他具體談到了常量泛型（const generics），他說，這將是一個(gè)很適合在內(nèi)核環(huán)境中使用的功能。但是會(huì)不會(huì)有一天會(huì)變得必須禁用這個(gè)功能從而減少維護(hù)者的負(fù)擔(dān)？Ojeda 說，一些更高級(jí)的功能在 core 代碼中可能是有用的，但他更希望看到驅(qū)動(dòng)程序使用 Rust 語(yǔ)言中比較小的一個(gè)子集，避免像 "crazy metaprogramming" 之類的東西。
此時(shí)，會(huì)議的時(shí)間已經(jīng)用完了，與會(huì)者們?nèi)ズ瓤Х攘恕８钊氲挠懻摼头诺搅私酉聛淼膬商鞎r(shí)間里。超過 30 名開發(fā)者參加了這次會(huì)議，這表明人們對(duì)用 Rust 編寫內(nèi)核代碼這個(gè)想法有相當(dāng)大的興趣，即使這個(gè)功能目前還不在 mainline kernel 中。Rust in kernel 不是一個(gè)可以容易讓人們接受方案，但就算它最終失敗了，也不用后悔，畢竟都努力嘗試過了。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長(zhǎng)按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～