关于将Linux内核转换为支持现代C++代码的前景，一场已有六年历史的Linux内核邮件列表讨论重新燃起。
Linux内核主要由C代码和各种手写汇编语言组成，外加在Linux内核中支持Rust的不断增长的工作。虽然目前还不清楚是否有足够的份量使其成为现实，但一场关于Linux内核邮件列表的讨论已经重新开始，因为可能会看到Linux内核C代码在未来被转换为C++。
回到2018年4月1日，是一组45块补丁由RedHat工程师David Howells开始将内核转换为C++。这将允许主线内核利用内联模板函数、内联重载函数、类继承以及Linux内核当前不支持的其他特性及其C代码。那天很难进行认真的讨论，最终补丁在Linux内核邮件列表上存在了六年，没有太多讨论。
但是昨天，长期从事Linux开发的H.Peter Anvin回复了那个内核邮件列表的帖子。安文写LKML发表了一篇冗长的帖子，阐述了为什么Linux内核的C++最终可能是正确的时机：
安德鲁·平斯基最近注意到了这个帖子。我意识到它是在2018年4月1日发布的，要么是一个笑话，要么可能被认为是笑话。然而，我认为它是有道理的，我会在这里尝试激励我的观点。
自1999年以来，C和C++都有了很大的发展，事实上，在我个人看来，C++最终“成长为”了一个更好的C语言，用于操作系统内核所代表的那种嵌入式编程。我是说，作为内核中大量宏和内联汇编的作者。
真正让我这么说的是，我们最近要求的许多特定于gcc的扩展实际上在标准C++中相对容易实现，并且在许多情况下，允许在不更改全局代码的情况下改进基础设施（见下文）。
在我看来，C++14是具有合理元编程支持的“最低”版本，它的大部分内容没有早期版本的地狱类型(C++11拥有大部分内容，但C++14填补了一些关键的缺失部分)。
然而，在我看来，C++20确实是主要的游戏规则改变者；尽管早期版本可以玩很多SFINAE黑客，但它们也给出了绝对无用的呕吐作为错误消息。C++20增加了概念，这使得实际获得合理的错误成为可能。
对于那些可能会提出“用铁锈重写C代码！”的人，Anvin在他的消息中积极地补充道：
“现在，“为什么不生锈”？首先，Rust使用了不同的语法（在我看来，通常是无偿的），不仅所有内核开发人员都需要非常熟悉，以获得与C相同的“感觉”，而且将C代码转换为Rust并不是一件可以零碎完成的事情，而通过一些清理，现有的C代码可以编译为C++。
然而，我发现我不同意David的一些结论；事实上，我认为David是不必要的“悲观”的，至少在现代C++中是这样。
请注意，没有一个头脑清醒的人会期望使用C++的所有功能。就像我们有“内核C”（目前是C11的一个子集，有一组相对较大的允许的编译器特定扩展）一样，我们将有“内核C++”，我建议它是C++20的一个严格定义的子集，并结合了一组类似的编译器扩展。我意识到C++20编译器支持仍然是非常新的，原因很明显，所以至少有一些是前瞻性的。”
SUSE Lans的Jiri Slaby已经出来支持Linux内核的C++计划。最初发布内核补丁的红帽公司的大卫·豪厄尔斯也支持这一讨论。
我们拭目以待这个LKML讨论引导了 如果在2024年以后，Linux内核中终于有足够的动力支持现代C++代码--或者至少是一些定义的C++14的20子集。Linus Torvalds过去一直强烈反对C++，但我们将看到潮流是否最终转向，如果他对最近的C++标准更满意，或者如果他仍然坚持将Linux内核保持在C中。
直到2022年，Linux内核才开始从C89迁移到C11. Especially if there is consensus to permit a subset of C++14/C++20 programming in the kernel, it may still be some time before it's adopted to allow for broader compiler support to roll out before raising the base compiler requirements and even if receiving the miraculous endorsement of Torvalds it's not a decision to be taken lightly.
