Updated Rust Code For Linux Kernel Patches Posted

[CommunityMember]

I don't know why the hurry to implement Rust if GCC-RS is not completed yet.

That was a self imposed slow-walk by the gcc community due to their choices of approaches. And while I would expect that the gcc team will eventually complete their release, should they stumble they will be left in further catch up mode behind the rust reference compiler (as always in open source, let the better implementation lead).

[bug77]

When did "we devs don't wanna have to learn another language" become "potentially lowering the barrier to contributing to the kernel"?

Learning Rust is a lower barrier than learning to properly multithread in C.

[bug77]

There are some problems with the Rust language:

• Long compile times / slow build
• The resulting binary produced is large
• You cannot declare async functions inside a trait
• Libraries built using a async runtime are incompatible with other libraries built using a different async runtime

And this is in stark contrast to other languages which are typically problem-free

[linner]

Yay, more bloat and less performance. Just what a kernel needs. Just get a bigger faster computer to make up for the poor software, problem "solved", like always.

[intelfx]

There are some problems with the Rust language:

• Long compile times / slow build

This might be a genuine problem, but typically it's seen in context of crate bloat (where, if your program has a large list of dependencies, Node.js/Python-style, you have to compile them along with your code, and compilation times add up). In context of kernel development, crate bloat likely won't be a thing at all.

• The resulting binary produced is large

This is simply due to the fact that the Rust standard library is always linked statically (while in languages people tend to compare Rust to, the standard library is often linked dynamically). Again, this can be a genuine problem in other contexts, but in context of kernel development the standard library will not used at all (or maybe a very restricted variant thereof) and there is no choice of linking it statically or dynamically. The generated code itself is not particularly large or bloated.

• You cannot declare async functions inside a trait

Compared to a language that does not have either async functions or traits, this is a problem how exactly?

• Libraries built using a async runtime are incompatible with other libraries built using a different async runtime

Same.

[V1tol]

You cannot declare async functions inside a trait

async-trait crate solves this problem for now. That also shows the power of language - extendability.

Libraries built using a async runtime are incompatible with other libraries built using a different async runtime

I know only two big async runtimes - tokio and async-std. And 99% of libraries I've seen and/or used are built around tokio. At least this language has ability to plug in async runtimes. Who also allows that? I think in future we will see special kernel async runtime based on kernel magic (if that thing exists at all).

Yay, more bloat and less performance. Just what a kernel needs. Just get a bigger faster computer to make up for the poor software, problem "solved", like always.

Aw yes, we've been waiting for you. Behold, here goes expert in compiled languages and kernel who knows everything about Rust.

[ZuseZ4]

This might be a genuine problem, but typically it's seen in context of crate bloat (where, if your program has a large list of dependencies, Node.js/Python-style, you have to compile them along with your code, and compilation times add up). In context of kernel development, crate bloat likely won't be a thing at all.
Same.

While I mostly agree with you, we should keep in mind that rust works on crates as compilation units, while c works on files.
Also, the rust compiler is mostly sequential when it comes to compiling a single crate, which is sometimes worked around by splitting larger crates into multiple smaller ones.
I don't think people want to design the kernel according to compilation times.
So there is an issue here and progress is only slowly being made. However, I do see compilation times as an acceptable issue when at the same time solving more severe security issues. Also, we are making improvements (e.g. looking at LLVM's new PassManager) and I expect that cg_gcc is also going to help here.

[oiaohm]

There's no such thing as kernel C. It's just C and nothing remotely close to C++. The real challenge with kernel development is learning the ins and outs of the kernel itself which you will do regardless of C or Rust.

When it comes to the Linux kernel there is such thing as Linux kernel C.

https://www.kernel.org/doc/html/latest/dev-tools/sparse.html

Yes you have a static analyser with the Linux kernel that you have to add annotations to your C code so your C code is acceptable. Yes those annotations for sparse can at times make it tricker to take code from the Linux kernel and put them in a different OS that is general C kernel.

Yes there are quite a few faults that you can code in general C that when you run builds with Linux with sparse on come build failures with the Linux kernel. So mainline Linux kernel C does not have the same list of failures as normal C and part because the Linux kernel C is extended.

[bug77]

This is simply due to the fact that the Rust standard library is always linked statically (while in languages people tend to compare Rust to, the standard library is often linked dynamically).

It's actually because Rust statically links stdlib. But only by default, it can be linked dynamically as well.
There's also work on statically linking only the parts of stdlib that are actually used, in order to further decrease the executable size, but afaik, nothing's mainlined yet.

It can be a problem for embedded development, but it's acknowledged and being worked on. I don't see how it would be a problem in this context, Rust is supposed to be used for device drivers at first.

[ssokolow]

I know only two big async runtimes - tokio and async-std. And 99% of libraries I've seen and/or used are built around tokio. At least this language has ability to plug in async runtimes. Who also allows that? I think in future we will see special kernel async runtime based on kernel magic (if that thing exists at all).

Not to mention the reason that incompatibility occurs... there are still APIs that should be common which haven't yet gone through the design and proving process for inclusion in the standard library, so you're temporarily seeing the equivalent of "there's no standard for graphical APIs in BASIC" or "POSIX is very incomplete compared to the APIs most C programs for Linux or Win32 actually use these days".

Give it time. They're currently hammering out things like the std replacement for lazy_static and once_cell. If they hadn't waited on that, we'd be stuck with a lazy_static-style API when the younger once_cell proved to be the better design that's getting adopted.