The use of C++ in Linux has been proposed again
It seems that the introduction of Rust as a second language programming in the Linux Kernel has represented one of the most important changes that Linux has had and not speaking in the scope of features and functionalities, but it has marked a very important starting point in how Linus Torvalds and the development team have taken a significant step towards modernizing Linux for the better.
This can be noted, since recently, on Linux kernel mailing lists a discussion has been revived which was started six years ago, jokingly presenting April 1, 2018.
And it has been put back on the table again. the issue of “the feasibility of adopting modern C++ code in the Linux kernel”, going beyond the traditional use of the C language with assembler fragments and the promotion of the Rust language.
The initial proposal was launched in 2018, by a Red Hat engineer as a joke for the well-known April's fool celebration, in which many take the opportunity to create pranks on the community and at that time it was like that, since it had supposedly released a set of 45 patches that included the use of templates, class inheritance and overloading of C++ functions.
In my opinion, C++14 is the “minimal” version that has reasonable metaprogramming support and has most without the types from previous versions (C++11 had most, but C++14 fills in some key missing pieces). However, in my opinion, C++20 is really the biggest game changer; Although previous versions could execute many SFINAE hacks, they also gave absolutely useless error messages.
We do a lot of metaprogramming in the Linux kernel, implemented using often really horrible macro tricks. These are also virtually impossible to debug. Let's take the example of uaccess.h type hacks, some of which I designed and wrote. In C++, different casts and case statements can be split into separate template instances, and with a little ingenuity, things like userspace pointers versus kernel userspace pointers can also be strictly enforced, as well as already marked userspace pointers, versus those that are not, not to mention the easy handling of the case of 32-bit userspace types in a 64-bit kernel and the application of endian conversion.
Now almost after 6 years of this, Hans Peter Anvin, a key Intel kernel developer and creator of projects such as syslinux, klibc and LANANA, has taken up the initiative to continue the discussion. According to Anvin, since 1999, the C and C++ languages have seen significant advances in their development, and the C++ language has proven to be more suitable than C for operating system kernel development.
Anvin mentions that features that previously required specific extensions from GCC, can now be easily implemented in standard C++, and in many cases, using C++ will improve the infrastructure without needing to completely change the code.
In addition to that, It is proposed to use at least the C++ 14 specification, which includes metaprogramming tools, and the use of the C++ 20 specification is encouraged, which introduces support for concepts that can reduce the incidence of errors.
It is argued that C++ is more preferable than Rust, since the latter differs significantly in syntax from the C language, is uncommon for current kernel developers and does not allow gradual code rewriting. In the case of the C++ language, it is possible to translate parts of the C language code gradually, similar to how C code can be compiled as C++.
While the Linux kernel is primarily C code with various parts written in assembly and growing work around Rust support in the Linux kernel, it is still unclear if there is enough weight for this to be a reality, on the possibility of seeing Linux kernel C code converted to C++ in the future.
finally if you are interested in knowing more about it, you can check the details in the following link