Linux 內(nèi)核應(yīng)從 C 轉(zhuǎn)到 C++！

發(fā)布時(shí)間：2024-01-15 09:29:42

前有 C 語言當(dāng)?shù)?，后?Rust “殺入”，時(shí)下又有一場關(guān)于 C++ 才應(yīng)該成為 Linux 內(nèi)核語言的爭論被舊事重提了。

1 月 9 日，Linux 基金會技術(shù)顧問委員會員、長期從事 Linux 內(nèi)核開發(fā)的 H. Peter Anvin 寫了一篇長長的 LKML（Linux Kernel Mailing List，Linux 內(nèi)核郵件列表）帖子，推翻 Linus Torvalds 多年前的一句“C++ 真是一門很爛的語言”言論，其認(rèn)為「現(xiàn)在是 Linux 內(nèi)核從 C 語言轉(zhuǎn)向 C++」的正確時(shí)機(jī)。

重啟停滯六年的討論！

之所以稱之為舊事重提，實(shí)際上，早在 2018 年 4 月 1 日，紅帽工程師 David Howells 發(fā)布了一組 45 個(gè)補(bǔ)丁，開始將 Linux 內(nèi)核轉(zhuǎn)換為 C++。這將允許主線內(nèi)核使用內(nèi)聯(lián)模板函數(shù)、內(nèi)聯(lián)重載函數(shù)、類繼承以及其他目前 Linux 內(nèi)核的 C 代碼不支持的功能。

但是彼時(shí)因?yàn)橹T多因素，討論未能進(jìn)行下去，最終那些補(bǔ)丁在 Linux 內(nèi)核郵件列表上停留了六年，沒有引起太多關(guān)注。

時(shí)間回到當(dāng)下，作為 Linux 內(nèi)核的重要參與者，H. Peter Anvin 發(fā)現(xiàn)了這條帖子的存在，他表示，紅帽工程師 David Howells 在 2018 年分享這個(gè)觀點(diǎn)時(shí)，在不少人來看，要么是個(gè)玩笑，要么可能被當(dāng)成了玩笑。

不過，結(jié)合時(shí)下最新的 C++20 等版本來看，其率直地表示，“大家好，我要捅馬蜂窩，做一件褻瀆神明的事...我認(rèn)為它有其合理性，我將在此嘗試分享我的觀點(diǎn)?！?/span>

現(xiàn)在是將 Linux 內(nèi)核的 C 轉(zhuǎn)為 C++ 的最好時(shí)機(jī)？

H. Peter Anvin 認(rèn)為，自 1999 年以來，C 和 C++ 都有了長足的發(fā)展，而站在其視角，他發(fā)現(xiàn) C++ 終于“長大”了，對于操作系統(tǒng)內(nèi)核所體現(xiàn)的嵌入式編程而言，它是一種更好的 C 語言。

“我是作為內(nèi)核中大量宏和內(nèi)聯(lián)匯編 Hacks 的作者才這么說的”，H. Peter Anvin 說道，“讓我有此感覺的真正原因是，Linux 最近提出的許多針對 GCC 擴(kuò)展的要求，其實(shí)在標(biāo)準(zhǔn) C++ 中很容易實(shí)現(xiàn)，而且在許多情況下，無需修改全局代碼即可改進(jìn)基礎(chǔ)架構(gòu)。”

H. Peter Anvin 表示：

C++14 是擁有合理元編程支持的“最低”版本，它擁有大部分元編程支持，卻沒有早期版本的類型地獄（C++11 擁有大部分元編程支持，但 C++14 填補(bǔ)了一些關(guān)鍵缺失）。

此外，C++20 才是真正改變游戲規(guī)則的主要因素。雖然早期版本可以使用大量 SFINAE hacks（Substitution Failure Is Not An Error，是 C++ 語言中的一種特性，允許開發(fā)人員在編譯時(shí)根據(jù)類型條件來選擇模板的特化版本），但它們也提供了完全無用的錯(cuò)誤信息。C++20 增加了一些概念，這使得真正獲得合理的錯(cuò)誤信息成為可能。

在對 Linux 的不斷實(shí)踐中，H. Peter Anvin 透露，其在 Linux 內(nèi)核中進(jìn)行了大量的元編程，這些代碼通常使用一些極其糟糕的宏定義來實(shí)現(xiàn)，而且?guī)缀鯚o法調(diào)試。例如 uaccess.h 中的類型欺騙，其中一些是 H. Peter Anvin 設(shè)計(jì)和編寫的。

相比之下，C++ 可以通過各種類型轉(zhuǎn)換和 case 語句將其分解成單獨(dú)的模板實(shí)例，而且通過一些巧妙的方法，還可以嚴(yán)格地強(qiáng)制區(qū)分用戶空間指針與內(nèi)核空間指針、已驗(yàn)證與未驗(yàn)證過的用戶空間指針等事項(xiàng)，更不用說輕松處理 64 位內(nèi)核中 32 位用戶空間類型的情況，并強(qiáng)制執(zhí)行字節(jié)序轉(zhuǎn)換。

Linus 曾怒噴：“C++ 真是一門很爛的語言”

在 H. Peter Anvin 看來，C++ 已經(jīng)有了不少改進(jìn)，現(xiàn)在讓 Linux 內(nèi)核去嘗試 C++ 語言，未嘗不是一件壞事。

但是，在不少網(wǎng)友眼中，此事估計(jì)有點(diǎn)懸，畢竟曾經(jīng)還年輕、脾氣也火爆的 Linus Torvalds 在多個(gè)場合公開吐槽過 C++。

在 2007 年，有位名為 Dmitry Kakurin 的開發(fā)者查看了 Git 源代碼發(fā)現(xiàn)使用的是純 C 而非 C++ 后表示不可理解，另外還附帶了一句臟話。當(dāng) Linus 知曉此事后，直接進(jìn)行了反擊還怒批道，C++ 是一門糟糕的語言。它之所以糟糕，是因?yàn)橛泻芏嗨揭话愕某绦騿T使用它，導(dǎo)致代碼質(zhì)量低下。

那時(shí)的 Linus 也給出了自己不看好在 Linux 內(nèi)核上用 C++ 的幾層理由：

使用 C++ 庫（例如 STL 和 Boost）可能會帶來問題。這些庫可能不穩(wěn)定、不兼容，而且使用時(shí)可能會出錯(cuò)。

過度依賴抽象對象模型，會導(dǎo)致代碼難以優(yōu)化，甚至需要重寫。

同時(shí)，C++ 的一些優(yōu)勢在注重性能的項(xiàng)目中反而會帶來弊端。

2010 年，Linus 又在郵件列表中開始吐槽 C++，無論什么時(shí)候 C++ 都不可能是最正確的選擇，在系統(tǒng)編程里直接用 C 就可以，而在非系統(tǒng)編程里，有很多垃圾收集的語言可供選擇，而 C++ 只能用來搗亂。

近兩年間，脾氣開始轉(zhuǎn)好的 Linus 不僅減少了說臟話的頻次，也在 Linux 內(nèi)核中接納了另一門編程語言 Rust。

2021 年，Linux 內(nèi)核和 Rust on Linux 的主要開發(fā)者 Miguel Ojeda 向 Linux Kernel 郵件列表提交了一個(gè)新補(bǔ)丁，其中指出為 Linux 內(nèi)核增加對 Rust 作為第二語言的支持。

對于此舉，有網(wǎng)友提出質(zhì)疑，即當(dāng)代碼調(diào)用不安全函數(shù)時(shí)，Rust 的內(nèi)存安全就得不到保證了，而目前幾乎所有內(nèi)核 API 都在其中。

同時(shí)網(wǎng)友給出一個(gè)用 C++ 代替 Rust 的解決方案時(shí)，Linus 依然忍不住地說道：“C++ 根本解決不了 C 語言的問題，它只會讓事情變得越來越糟。那些不喜歡 C 語言的人可以去尋找真正能給你帶來價(jià)值的語言。比如具有內(nèi)存安全性并可以避免 C 導(dǎo)致的隱患的語言，或者具有內(nèi)部 GC（垃圾回收）支持并簡化內(nèi)存管理的語言。”

相比對 C++ 的不看好，Linus 對 Rust 則有耐心得多。在不久前的 Open Source Summit Japan 2023 上，Torvalds 談到 Linux 中 Rust 的最新進(jìn)展，“它一直在成長，但我們還沒有內(nèi)核的任何部分真正依賴 Rust。對我來說，Rust 是技術(shù)上有意義的事情之一，但對我個(gè)人來說，更重要的是，作為內(nèi)核和開發(fā)人員，我們不能停滯不前?！?/span>

盡管如此，Torvalds 繼續(xù)說道：“Rust 還沒有真正成為下一個(gè)偉大的事物。但我認(rèn)為，在明年，我們將開始集成驅(qū)動程序，甚至一些主要的子系統(tǒng)也將開始積極使用 Rust。因此，要讓它成為內(nèi)核的重要組成部分，還需要數(shù)年時(shí)間。但它肯定會成為內(nèi)核的一部分。”

H. Peter Anvin 不用 Rust 重寫 C 代碼的觀點(diǎn)

然而，在最新的討論中，H. Peter Anvin 似乎并不看好 Rust 在 Linux 內(nèi)核中的使用。

他補(bǔ)充說道，至于為什么不用 Rust 重寫 C 代碼：

首先，Rust 使用的是不同的語法，不僅所有內(nèi)核開發(fā)人員都需要非常熟悉才能獲得與 C 相同的“感覺”，而且將 C 代碼轉(zhuǎn)換為 Rust 并不是一件可以零敲碎打的事情，而現(xiàn)有的 C 代碼經(jīng)過一些清理就可以編譯為 C++。

不過，H. Peter Anvin 也在帖子中特別指出，沒有一個(gè)正常人會期望使用 C++ 的所有功能。就像 Linux 內(nèi)核中有“kernel C”（目前是 C11 的一個(gè)子集，包含一組相對較大的允許編譯器特定擴(kuò)展）一樣，H. Peter Anvin 認(rèn)為也可以有“Kernel C++”，他建議它是 C++20 的一個(gè)嚴(yán)格定義的子集，包含一組類似的編譯器擴(kuò)展。

“我意識到，由于顯而易見的原因，C++20 的編譯器支持仍然非常新，因此至少其中一些是前瞻性的”，H. Peter Anvin 說道。

拭目以待

眾所周知，Linux 內(nèi)核主要是用 C 語言編寫的，但也包含了少量的匯編語言代碼，加上 Linux 內(nèi)核支持 Rust 的工作也在不斷增加，現(xiàn)在又提出要用 C++ 來寫，無疑也引起了巨大的爭議。

對于最新提案，據(jù)外媒 phoronix 報(bào)道，SUSE Lans 的 Jiri Slaby 表示支持 Linux 內(nèi)核的 C++ 計(jì)劃。最初發(fā)布內(nèi)核補(bǔ)丁的紅帽公司的 David Howells 也表示支持這一討論。

也有很多網(wǎng)友表示支持：

我完全同意。就像他們已經(jīng)在使用 C11 標(biāo)準(zhǔn)的子集一樣，Linux 也可以遷移到現(xiàn)代 C++ 的子集上。如果 OOP、異?；?RTTI 在內(nèi)核中沒有意義的話，Linux 就不需要使用它們，但用更安全的模板元編程和概念來取代 C 語言中容易出錯(cuò)的宏，會讓錯(cuò)誤較少的代碼編程變得更容易。

SerenityOS 目前使用的是一種非常獨(dú)特的現(xiàn)代 C++ 編程風(fēng)格，并帶有一個(gè)自定義標(biāo)準(zhǔn)庫。

我希望 Linus 對 C++ 的看法在過去二十年中有所改變，因?yàn)閺哪菚r(shí)起，C++ 已經(jīng)成為一種大不相同（而且更好）的語言。

在 HN 上，不少開發(fā)者卻持相反意見：

現(xiàn)代 C++ 并沒有解決 Linus 最初反對它的理由。我也不同意添加 C++ 比使用 Rust 更省力的說法。C 和 C++ 已經(jīng)天差地別。了解 C 意味著你基本可以用 C++ 編寫 C（而且只是基本），但這并不意味著你了解 C++ 了。也許在 30 年前，你可以向 C 程序員展示 C++ 是如何編譯成 C 語言的，這就足以讓 C 程序員開始對 C++ 大加撻伐，但那一天早已過去。至于讓內(nèi)核開發(fā)人員學(xué)習(xí) Rust 更容易還是學(xué)習(xí) C++ 更容易，考慮到內(nèi)核開發(fā)人員幾乎需要學(xué)習(xí) C++ 的全部內(nèi)容、每一個(gè)怪癖和每一個(gè)細(xì)節(jié)，老實(shí)說，Rust 在這方面還是有優(yōu)勢的。

我希望他們能選擇與 C++ 不同的東西，也許是 Zig。C++ 的問題在于，就像 Scala 一樣，你很難堅(jiān)持使用一個(gè)子集，而不會在事后意識到你使用了超出預(yù)期的內(nèi)容。也許內(nèi)核團(tuán)隊(duì)可以做到這一點(diǎn)，因?yàn)樗麄冇幸环N保持簡潔的文化。

雖然目前還不清楚是否有足夠的力量將其變?yōu)楝F(xiàn)實(shí)，但 Linux 內(nèi)核郵件列表已經(jīng)重新開始討論未來將 Linux 內(nèi)核 C 代碼轉(zhuǎn)換為 C++ 的可能性，很多人也想了解 Linus 對此的觀點(diǎn)是否隨著時(shí)間的推移以及 C++ 的改進(jìn)迭代而發(fā)生了變化，我們也將對 LKML 討論的結(jié)果拭目以待。

————————————————