Linux 內(nèi)核對(duì)Rust的支持可能涉及到的三個(gè)方面

從去年九月，Linux 內(nèi)核維護(hù)者 Greg 表示愿意接受用 Rust 開發(fā) Linux 驅(qū)動(dòng)，到今年七月，Linus Torvalds 回應(yīng)稱可以默認(rèn)啟用 Rust 支持，Linux 開發(fā)者并非只是說(shuō)說(shuō)而已。

在八月底舉辦的 2020 Linux Plumbers 大會(huì)上，關(guān)于 Linux 內(nèi)核上游對(duì) Rust 的開放程度成為了最熱門的討論話題。Rust 語(yǔ)言團(tuán)隊(duì)的聯(lián)合負(fù)責(zé)人 Thomas 和 Gaynor，以及 Linux 內(nèi)核開發(fā)者 Josh Triplett 等人參與了這場(chǎng)討論，并向大家展示了截至目前的一些研究成果、想法，還有遇到的問(wèn)題。

他們強(qiáng)調(diào)，并不打算將已有的內(nèi)核改寫成 Rust，而只專注于可以用 Rust 編寫的新代碼。具體來(lái)講，與會(huì)者集中討論了 Linux 內(nèi)核對(duì) Rust 的支持可能涉及到的三個(gè)方面：內(nèi)核中現(xiàn)有的 API、架構(gòu)支持，和 ABI 與內(nèi)核的兼容性問(wèn)題。

綁定到現(xiàn)有的 C API

目前來(lái)看，Rust 能夠生成可以鏈接到內(nèi)核的代碼還不夠。它還需要一種方法來(lái)訪問(wèn) Linux 內(nèi)核中使用的大量 API，這些 API 目前都在 C 頭文件中定義。

Linux 內(nèi)核開發(fā)者指出，Rust 與 C 具有良好的互操作性;此外，bindgen 工具能夠解析 C 頭文件以生成適當(dāng)?shù)?Rust 聲明，因此 Rust 不需要從 C 復(fù)制重復(fù)的定義，這也提供了一種跨語(yǔ)言類型檢查的措施。

從表面上看，這些特性使 Rust 具備了與現(xiàn)有 C API 集成的良好條件，但實(shí)際上實(shí)施起來(lái)還存在一些挑戰(zhàn)。例如，Linux 大量使用了預(yù)處理器宏和內(nèi)聯(lián)函數(shù)，bindgen 和 Rust 的外函數(shù)接口不容易支持它們。

有關(guān) API 綁定的第二個(gè)問(wèn)題是：需要手動(dòng)封裝多少 C API 才能呈現(xiàn)慣用的 Rust 接口？

Thomas 和 Gaynor 展示了一個(gè) linux-kernel-module-rust 項(xiàng)目，可在其中看到內(nèi)核模式的 Rust 代碼示例。在這個(gè)項(xiàng)目中，指向用戶空間的指針被封裝到 UserSlicePtr 類型中。這樣的封裝生成的代碼對(duì)現(xiàn)有 Rust 開發(fā)者而言更加熟悉，并使 Rust 的類型系統(tǒng)和借用檢查器提供最大程度的安全性。但是，必須針對(duì)每個(gè) API 進(jìn)行設(shè)計(jì)和開發(fā)，用 C 和 Rust 編寫的模塊也會(huì)創(chuàng)建不同的 API。這無(wú)疑加重了工作的繁瑣度。

John Baublitz 也給出了一個(gè)演示模塊，它更直接地綁定了內(nèi)核的用戶訪問(wèn)功能，綁定多由 bindgen 自動(dòng)生成。然而，Rust 開發(fā)者對(duì)這些代碼可能會(huì)不太習(xí)慣，并且這種方式可能需要放棄 Rust 的許多安全保證。

最后，會(huì)議達(dá)成了共識(shí)：對(duì)于某些最常見和關(guān)鍵的 API，編寫 Rust 封裝器是有意義的，但是手動(dòng)封裝每個(gè)內(nèi)核 API 不可行。Thomas 還提到谷歌正致力于自動(dòng)生成 C++ 代碼的慣用綁定，并考慮內(nèi)核是否可以做類似的事情。

架構(gòu)支持

對(duì)架構(gòu)的支持是討論的另一個(gè)重點(diǎn)。與會(huì)者表示，在 Rust 中實(shí)現(xiàn) Linux 驅(qū)動(dòng)是可以接受的，但無(wú)論如何不能把它放在更晦澀難懂的架構(gòu)上。

在這方面，現(xiàn)階段唯一成熟的 Rust 實(shí)現(xiàn)是 rustc 編譯器，該編譯器通過(guò) LLVM 發(fā)出代碼。Linux 內(nèi)核支持多種架構(gòu)，其中一些沒(méi)有可用的 LLVM 后端，另一些存在 LLVM 后端，卻尚不受 rustc 支持。

Triplett 認(rèn)為，先將 Rust 添加到 Linux 內(nèi)核中，反過(guò)來(lái)會(huì)有助于增加對(duì)更多架構(gòu)的 Rust 支持。就像 Rust 軟件被引入 Debian 后，吸引了更多不同架構(gòu)的愛(ài)好者協(xié)助改進(jìn) Rust 支持一樣，他寄希望于為 Linux 內(nèi)核添加 Rust 支持也獲得類似的效果。

ABI 與內(nèi)核的兼容性

Gaynor 問(wèn)到了有關(guān) ABI 兼容性的建議。當(dāng)前 Rust 是通過(guò) LLVM 編譯的，而 Linux 內(nèi)核通常使用 GCC 構(gòu)建，因此將 Rust 代碼鏈接到內(nèi)核可能意味著混合 GCC 和 LLVM 發(fā)出的代碼。

參與討論者擔(dān)心 LLVM 與 GCC 可能會(huì)有 ABI 兼容的問(wèn)題，于是提出一個(gè)設(shè)想，即 Linux 內(nèi)核社區(qū)是否可以將 Rust 支持僅限于使用 Clang 構(gòu)建的內(nèi)核，以確保兼容性。

Linux 內(nèi)核維護(hù)者 Greg 指出，當(dāng)前的內(nèi)核規(guī)則是，僅當(dāng)內(nèi)核中的所有目標(biāo)文件使用相同的編譯器并使用相同的標(biāo)志構(gòu)建時(shí)，才能保證兼容性。不過(guò)，他仍然對(duì)將 LLVM 構(gòu)建的 Rust 對(duì)象鏈接到 GCC 構(gòu)建的內(nèi)核表示滿意，因?yàn)橹灰渲眠m當(dāng)，并通過(guò)測(cè)試即可。他認(rèn)為不需要任何預(yù)先的限制，直到真正有實(shí)際問(wèn)題產(chǎn)生。

另一位內(nèi)核開發(fā)者 Triplett 也強(qiáng)調(diào)，GCC 和 Rust 之間的調(diào)用是常規(guī)且普遍的，不必?fù)?dān)心兼容性。因此目前看來(lái)，二者的兼容性問(wèn)題目前不會(huì)成為將 Rust 引入 Linux 內(nèi)核的阻礙。

這場(chǎng)會(huì)議上的討論大致到此，暫時(shí)沒(méi)有后續(xù)消息。隨著越來(lái)越多的人對(duì)此抱有期待和熱情，正如 LWN.net 所說(shuō)，或許待一個(gè)具體的 Rust 內(nèi)核驅(qū)動(dòng)用例出現(xiàn)時(shí)，所有的爭(zhēng)議和決策都將變得更加清晰。
責(zé)編AJX