A six-year-old Linux kernel mailing list discussion has been reignited over the prospect of converting the Linux kernel to support modern C++ code. The existing Linux kernel is mainly composed of C code and various hand-written assembly languages, and the work of supporting Rust in the Linux kernel is also increasing. While it's unclear whether there will be enough power to make this a reality, the Linux kernel community mailing list has restarted discussions on the possibility of converting Linux kernel C code to C++ in the future.
As early as April 1, 2018, Red Hat engineer David Howells proposed a set of 45 patches to begin converting the kernel to C++. This will allow the mainline kernel to use inline template functions, inline overloaded functions, class inheritance, and other features not currently supported by the Linux kernel's C code. It was difficult to have a serious discussion that day, and ultimately the patches sat on the Linux kernel mailing list for six years without much discussion.
But yesterday, long-time Linux developer H. Peter Anvin responded to the kernel mailing list topic. Anvin wrote a lengthy LKML post laying out his reasoning around why C++ for the Linux kernel might finally be the right time:
"Andrew Pinski recently became aware of this topic. I understand it was posted on April 1, 2018 and was either a joke or could have been taken as a joke. However, I think it has merit and I will try to inspire my perspective here."
Both C and C++ have come a long way since 1999, and in fact, in my personal opinion, C++ has finally "grown up" and is a better C language for embedded programming embodied in the operating system kernel. I say this as the author of numerous macro and inline assembly hacks in the kernel.
The real reason I say this is that many of the recent requests we've made for gcc extensions are actually very easy to implement in standard C++, and in many cases improve the infrastructure without modifying global code.
In my opinion, C++14 is the "minimum" version with reasonable metaprogramming support. It has most of the metaprogramming support without the type hell of earlier versions (C++11 has most of the metaprogramming support, but C++14 fills in some key gaps).
In my opinion, C++20 is the real game-changer; while there are plenty of SFINAE hacks available for earlier versions, they also provide completely useless error messages. C++20 adds some concepts that make it possible to actually get reasonable error messages."
For those who might ask "rewrite C code in Rust!", Anvin proactively added in his message:
"Now, why not use Rust? First, Rust uses a different syntax (often gratuitous, in my opinion) that not only all kernel developers need to be very familiar with to get the same 'feel' as C, but converting C code to Rust is not a piecemeal thing that can be done piecemeal, while existing C code can be compiled to C++ with some cleanup."
SUSELans' Jiri Slaby expressed support for the Linux kernel's C++ initiative. David Howells of Red Hat, which originally released the kernel patch, also expressed support for this discussion.
We'll wait and see the outcome of the LKML discussions and whether there's finally enough momentum in 2024+ to support modern C++ code - or at least some defined subset of C++14~20 - in the Linux kernel. Linus Torvalds has been an ardent opponent of C++ in the past, but if he becomes more comfortable with the recent C++ standard, or if he still insists on using C to maintain the Linux kernel, then we can see if the tide finally turns.
It will not be until 2022 that the Linux kernel begins to move from C89 to C11. Especially if consensus is reached to allow a subset of C++14/C++20 programming in the kernel, it may still be some time before the basic compiler requirements are raised to allow for broader compiler support to be rolled out.