Google Supports Getting Rust Into The Linux Kernel

[phoronix]

Phoronix: Google Supports Getting Rust Into The Linux Kernel

It should come as little surprise -- especially given the recent news of Google allowing Rust to be used for Android system-level code -- but engineers at the search giant are in support of Rust code being used within the mainline Linux kernel...

https://www.phoronix.com/scan.php?page=news_item&px=Google-Supports-Rust-Kernel

[birdie]

Linus does not and Rust developers agree with his reasoning. Once the voiced issues are resolved, it may be greenlit.

[ddriver]

Linus does not and Rust developers agree with his reasoning. Once the voiced issues are resolved, it may be greenlit.

Fork Linux!!!

[Alexmitter]

Google should invest in https://rust-gcc.github.io/ if they even wanna see rust in the kernel.

[bug77]

Linus does not and Rust developers agree with his reasoning. Once the voiced issues are resolved, it may be greenlit.

Actually Linus does support Rust in the kernel. He does have some concerns, but so does everybody else. And that's normal at this stage.

Edit: Here's where Linus stands: https://arstechnica.com/gadgets/2021...-linux-kernel/

Also, current talks are not about including Rust in the kernel itself, but in kernel drivers. That's about the safest approach I can think of. It "taints" just some modules, not the kernel as a whole and they can be discarded with minimum damage if they doesn't pan out.

C won't go away in the next decade or two, but looking at Rust it's pretty clear it has grown from a language loved by enthusiasts to something the big players are starting to take stock of.

[kpedersen]

C won't go away in the next decade or two

C can't go away because it is the entire computing platform.

Rust stands a good chance of replacing C++ in the future. These concerns about Rust in the Linux kernel are actually very similar to the concerns of C++ in the kernel. As of yet this hasn't happened either. Obviously the Rust guys are a little bit more noisy and the language does offer a few extra benefits above C++ in terms of (enforced) safety that might just tip the scale.

[ssokolow]

C can't go away because it is the entire computing platform.

Rust stands a good chance of replacing C++ in the future. These concerns about Rust in the Linux kernel are actually very similar to the concerns of C++ in the kernel. As of yet this hasn't happened either. Obviously the Rust guys are a little bit more noisy and the language does offer a few extra benefits above C++ in terms of (enforced) safety that might just tip the scale.

Plus, Rust is more a middle-ground between C and C++ as far as implicitly triggered complex behaviour goes. (eg. In Rust, you don't have to carefully plan for which structs and classes are POD and which aren't, because Rust won't implicitly inject a vtable into your object layout as soon as you start using certain language features.)

[skeevy420]

Fork Linux!!!

I wouldn't be too surprised if that actually happened. Not for Rust reasons, but from the anti-GPL crowd. Google has been spearheading the anti-GPL movement on the userspace side for coming on a decade now so it wouldn't be out of character for them and/or anyone else to tackle the kernel next.

I wonder how much work actually would need to be done. While the kernel is technically under GPLv2, does anyone actually know what percentage of the kernel is actually GPLv2? The other day it was brought up that AMDGPU is around 10% of the kernel. It's MIT licensed so it doesn't have to be rewritten and could be basically be copy/pasted into a new kernel. How much of the kernel is like that? Under a GPL-compatible license and essentially able to be ported as-is to somewhere without the GPL.

[RahulSundaram]

I wouldn't be too surprised if that actually happened. Not for Rust reasons, but from the anti-GPL crowd. Google has been spearheading the anti-GPL movement on the userspace side for coming on a decade now so it wouldn't be out of character for them and/or anyone else to tackle the kernel next

This is entirely unlikely. The kernel userspace boundary makes GPL a non problem for Google especially now that they have treble in place. They only have a small fraction of the Linux kernel developers necessary to pull this off and many existing ones won't join a non GPL effort. Hiring an army of new engineers and have them understand all the nuances is not worth it when they could invest that into Fuchsia instead.

[AnAccount]

Linus does not and Rust developers agree with his reasoning. Once the voiced issues are resolved, it may be greenlit.

Just a clarification, that Linus is not against it as a concept, just the current state of it.

"on the whole I don't hate it" is a clear indication that he does actually if the issues can be resolved. And if you read the rest of the thread, they confirm that the issues raised by him is valid but they are also very much possible to fix and they are already working on that.

In summary, to be clear:
- On allocation: this is just our usage of `alloc` in order to speed development up -- it will be replaced (or customized, we have to decide how we will approach it) with our own allocation and data structures.
- On floating-point, 128-bit, etc.: the main issue is that the `core` library is a single big blob at the moment. I have already mentioned this to some Rust team folks. We will need a way to "cut" some things out, for instance with the "feature flags" they already have for other crates (or they can split `core` in to several, like `alloc` is for similar reasons). Or we could do it on our side somehow, but I prefer to avoid that (we cannot easily customize `core` like we can with `alloc`, because it is tied to the compiler too tightly).