Rust For Linux Kernel v9 Patches Trim Things Down Greatly For Easier Upstreaming

[kpedersen]

Why excludes references and RAII?
These two features does not obfuscate the logic like exceptions and are both zero-cost abstraction.

I agree with references. But RAII does hide a fair amount of implementation.
I am mainly just going by what subsets of C++ others use. For example MISRA.

[Volta]

Just implement a C++ library for the Linux with async and threading. It doesn't matter whether functionality is built-in in the language or exists as a library - someone need to implement it anyways.

There will be no c++ crap in the kernel if you didn't notice yet.

[jacob]

I also got the impression that Linus was not a fan of a language which has "userland-first" design features like transparently adding a vtable member in your struct or class if you want to use the language's syntactic sugar for dynamic dispatch and a tendency to encourage people to think in failure-by-exception.

IIRC Linus' objection against C++ in the kernel was mainly about memory management and about the C++ programmers whom he considers hopeless. He said that ensuring that those people won't get involved in Linux development was a sufficient reason to ban C++ from the kernel

[darkonix]

I bet you don't have much experience with C++. It's way more better and safer than C while maintain the same low level features and zero cost abstractions.

I have used C++ as a 'better C' replacement and it certainly has its uses. Having said that, I don't believe that it would provide any really significant advantages it in the Linux kernel and it would require extra effort to ensure that undesired C++ features are introduced.

It would be interesting to have an actual list concrete benefits and features that should be excluded because they are not appropriate for the Kernel to understand in more deep the real impact.

[ssokolow]

mainly about memory management

Wasn't part of that about C++ constructs like new/delete leaning on "allocation failure reported via exceptions"?

[piotrj3]

Wasn't part of that about C++ constructs like new/delete leaning on "allocation failure reported via exceptions"?

It is actually far worse, from one paper:

§4.1: “C++” projects commonly ban exceptions,because today’s dynamic exception types violate the zero-overhead principle,and do not have statically bound able space and time costs. In particular, throw requires dynamic allocation and catch of a type requires RTTI.—We must at minimum enable all C++ projects to enable exception handling and to use the standard language and library.This paper proposes extending C++’s exception handling to let functions declare that they throw a statically known type by value,so that the implementation can opt into an efficient implementation (a compatible ABI extension). Code that uses only this efficient exception handling has zero space and time overhead compared to returning error codes.

This is far worse then just "plugging" kernel allocator into STD (what theoretically can be done). It also implies that if anything under the hood of STD (or any feature) can't use exceptions (oh they do use exceptions) among few other things. For example MSVC for windows has flags to force disable exceptions and RTII. Practically means you simply can't use std, stl, raii, exceptions among many other things. And at this point C++ dumps down a lot to almost the level of C.

What you see in Rust? Ah that's right no_std. The issue is almost all nice features of C++ are hidden behind std or something you can't use in kernel mode.

[cj.wijtmans]

All you have to do is remove STL and create an "STL" and std "lib" that is kernel appropriate. The same amount of work that rust needs if not less. RAII has nothing to do with it whatsoever. And you are still left with lambda, objects, meta-programming etc. Knowing enough about the language that you know what to remove but then saying that you are left with C is beyond retarded.

[NobodyXu]

Practically means you simply can't use std, stl, raii, exceptions among many other things.

I think you mean rtti, not raii

[NobodyXu]

I agree with references. But RAII does hide a fair amount of implementation.
I am mainly just going by what subsets of C++ others use. For example MISRA.

Thanks for the reply, I don't have much experience with MISRA though my experience with RAII is that it is easier than manually free or execute some cleanup functions, especially when you have multiple error paths, you would have to use goto in C if you don't want to end up having duplicate code.

[Sergey Podobry]

There will be no c++ crap in the kernel if you didn't notice yet.

Actually what I want is just have C++ compatible Linux headers (as Windows has): don't use `private` and `new` as variable names, don't use crappy non-standard things like forward enums and provide standard C++ metaprogramming instead of gcc extensions (g++ has no such extensions as there are standard ways to accomplish the same functionality).