Rust Support In The Linux Kernel Undergoing Another Round Of Discussions

[Brane215]

In rust there is no way to temporarily disable a part of your code, like #if 0-#endif in C.

That's because Rust doesn't use preprocessor to dig around and shuffle the source text before compiling.
AFAIK you can do more than eqivalent in code. Just present false condition and let compiler snip that branch away, for example.

[WorBlux]

The point is not even memory safety as such but its PROVABILITY. It is possible to write code that is effectively memory safe in C but it's strictly impossible to prove it.

While there is no general method that can prove safety, there can be proofs for specific code. (Related to the Halting Problem) And heuristics will often catch the most common problems.

[jacob]

While there is no general method that can prove safety, there can be proofs for specific code. (Related to the Halting Problem) And heuristics will often catch the most common problems.

No silver bullet exists or can exist, but in Rust it is possible to statically prove certain invariants (including, but not only, memory related) that cannot be proven in C. Heuristics are better than nothing but essentially in this case they will take you at best somewhere on the level of C++ >= 11.

[jacob]

Alright let me ask you this: would you compile your kernel with a compiler that's 50% faster for an executable that runs half as fast or would you use a compiler that's more complicated and thus takes longer, producing optimized code? Surely everyone here would take the latter.

What about same proposal but instead you can choose either a compiler that's 50% faster, and produces executables that run the same speed as the other, but the other one can remove 65-90% of all security bugs in the final executable?

Now let's make this more real world, let's hold the kernel at 30 million lines and say it takes 30 minutes to build on an arbitrary system now lets make the rust code 3 million lines and to make it favorable to you let's say it takes twice as long to compile rust as it does C, you added a whole 6 minutes to the build. Certainly nothing to cry over on a compile that takes a half hour anyway.

This is what you're complaining about.

Now if this was Scala where sbt takes a good 5 minutes on its own to start up before you can even run your compile command I might be more understanding, but that's not what we're talking about here.

It is true that Rust compile times are slower than C's, which is understandable because the the compiler does lot more work than a C compiler. This is even though compile times in C are in fact unnecessarily long because of the preprocessor and the header files, which essentially force the compiler to parse the same code over and over and over again.

It is also true that Rust is much more demanding than C in terms of compiler optimisation. An unoptimised debug build in Rust runs order of magnitude slower than an optimised build (or than C), and enabling optimisation makes the compile times much slower still.

[oleid]

It will be interesting to see how this will change once gcc-rs enters the ring. Also, the quality of debug builds should increase when the cranelift backend lands. It will replace llvm for debug builds eventually.

[piotrj3]

As a C programmer I resist the idea of adding Rust, when I can literally predict the resulting assembly language of my C program; due to my safe programming practices, and avoidance of ill formed code.

But when I try to argue against Rust I find things such as Oso Polar which bolster its inclusion; still I resist.

Personally i just find it a beauty of C. Converting in head C to ASM and viceversa is quite easy. Converting Rust or C++ is hard. Still most of time you do not need such knowdlege, eg. I find Rust perfect language to write something like parser.

[programmerjake]

Personally i just find it a beauty of C. Converting in head C to ASM and viceversa is quite easy. Converting Rust or C++ is hard. Still most of time you do not need such knowdlege, eg. I find Rust perfect language to write something like parser.

Well, any of Rust, C, or C++ all become very non-1:1 with the resulting assembly when using any decent modern optimizing compiler (such as gcc, clang, icc, or msvc).

Example of C with clang 12:

https://gcc.godbolt.org/z/6TPo4fEjT

[WorBlux]

No silver bullet exists or can exist, but in Rust it is possible to statically prove certain invariants (including, but not only, memory related) that cannot be proven in C. Heuristics are better than nothing but essentially in this case they will take you at best somewhere on the level of C++ >= 11.

Yes the invariants make it easier to reason about Rust code. but that's not to say you can't construct certain proofs around C or even assembly to prove a match to an specification. (As the L4 kernel does). And then there are tools like Valgrind or infer, which can catch a lot of mistakes.

And you could also end up in a situation where you implement a specification properly in Rust, only to find out that the specification itself is flawed in some way. As you said, there's no silver bullet.

I'm not really sure of what the proper role of Rust in the Linux kernel is, but it's certainly intriguing. Time will tell how well it can be integrated.

[jacob]

Yes the invariants make it easier to reason about Rust code. but that's not to say you can't construct certain proofs around C or even assembly to prove a match to an specification. (As the L4 kernel does). And then there are tools like Valgrind or infer, which can catch a lot of mistakes.

That by itself is not a vindication of C. You can also prove some invariants (to an even lesser degree) in pure assembly. If your goal was strictly to do OOP, the fact that you can use things like GObject in C doesn't mean that Python is not an infinitely better OOP language.

In other words, I'm not aware of anything that can be proven about C code that cannot be proven more easily in Rust. Of course Valgrind etc. can be, an are, used for Rust as well.

I'm not hating C here; for decades it was the only language other than assembly that could actually be used for low level systems programming. But we should beware of the Baby Duck syndrome; the fact that something was done in C for lack of other options doesn't mean that C is somehow ideal for that or that it can't be superseded. I can see a role for C well into the future by the way; while unsafe Rust can be used for extremely low level code (say, a context switch), it's just easier and more straightforward to write it in C. When writing C, one can essentially "see through" and visualise the underlying assembly that the compiler will generate, not so in Rust (at least I can't). But on the other hand, the Linux kernel also handles various highly complex data structures and sophisticated algorithms and those would definitely be better written in Rust.

And you could also end up in a situation where you implement a specification properly in Rust, only to find out that the specification itself is flawed in some way. As you said, there's no silver bullet.

When this happens, it's in fact an excellent outcome because you are served a proof that your spec is flawed and why. It's much preferable to the situation that happens routinely in C where a spec is happily implemented without anyone realising that it's flawed (because the flaw is usually non-obvious) and then you deal with bugs, vulnerabilities, race conditions and a code base that no-one dares to touch because it's a notorious minefield.

I'm not really sure of what the proper role of Rust in the Linux kernel is, but it's certainly intriguing. Time will tell how well it can be integrated.

Provability around memory safety, error handling and data races is certainly a major benefit for a kernel of all things.

Another benefit can be performance. C is not really the hyper efficient language that many people believe and the Rust memory model allows a compiler to perform various optimisations that are difficult or impossible in C, including autovectorisation, struct alignment tricks (or outright destructuration), autoparallelisation etc. You could say that at the moment Rust hasn't reached its full potential in that area; in most cases its runtime performance is somewhere around C or C++ (depending on the case) but the promise is there.

[ssokolow]

You could say that at the moment Rust hasn't reached its full potential in that area; in most cases its runtime performance is somewhere around C or C++ (depending on the case) but the promise is there.

*nod* Because LLVM's optimizers were developed for C and C++.

Even when they should support something Rust can do much better, it's tricky. For example, the Rust developers keep having to postpone attempts to turn on marking things noalias in the LLVM IR they emit because they keep revealing bugs in the LLVM optimizers that the much sparser use of restrict in C and __restrict__ in C++ don't trigger.