Rust heads into the kernel?

Posted Apr 22, 2021 11:53 UTC (Thu) by moltonel (guest, #45207)
In reply to: Rust heads into the kernel? by wtarreau
Parent article: Rust heads into the kernel?

The fact that kernel Rust will probably also need to handle similar READ_ONCE complications as kernel C doesn't make Rust less appealing. Rust will retain its borrow checker, sum types, safe/unsafe split, and other features that make it desirable. It already handles some very low-level hardware weirdness, and it's well equipped to accommodate whatever weirdness the kernel needs without turning the language into an unrecognizable mess.

It seems likely that initial kernel Rust code will have more 'unsafe' and less convenience than we can hope for 10 years down the line. If 10% of kernel "C functions" were initially asm, we can expect similar growing pains with Rust. So what ? Nobody is claiming that enabling Rust in the kernel will enable all Rust developers to become kernel developers. The main goal of Rust in the kernel is to make the kernel code better, not to attract Rust fans and newcomers.

Rust heads into the kernel?

Posted Apr 22, 2021 20:11 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (4 responses)

> Nobody is claiming that enabling Rust in the kernel will enable all Rust developers to become kernel developers.

Sorry but this is exactly how I understood it: make it easier to write drivers (implicit "for rust developers" as not everyone is fluent in it and even those used to it say the learning curve is pretty steep).

> The main goal of Rust in the kernel is to make the kernel code better, not to attract Rust fans and newcomers.

Better in terms of what ? Maintainability, with only 1% of kernel developers being able to review and fix that code instead of the previous 100% ? Ease of use, with everyone having to install two separate toolchains, some combinations of which will possibly cause trouble that will have to be detected and rejected ? Portability, with a number of existing architectures not even being implemented by the language ? Fame and ego for rust fanboys for having won a victory over Linux, maybe.

Rust heads into the kernel?

Posted Apr 22, 2021 20:36 UTC (Thu) by josh (subscriber, #17465) [Link]

You seem to be going out of your way to find the *least charitable interpretation possible* for everything. "fame and ego", really?

We wouldn't be working to enable Rust in the kernel if we didn't think it was an improvement *for the kernel*. The goal is to provide safety and productivity improvements. If you believe that Rust isn't actually achieving those goals, or that it does but that there are other factors outweighing that, by all means you're welcome to make the case for that.

Half your arguments would apply to *any* non-C language, no matter how much of an improvement it would otherwise be. Those arguments would effectively say that the kernel can never consider anything but C, and that "it isn't C" is a factor outweighing other considerations in any language evaluation.

Yes, a new toolchain and a new language has a baseline cost; the only reason Rust is being seriously considered is because *despite* that cost many people still think it'd be an improvement. I have confidence that kernel developers are quite *capable* of using something new, if it's deemed worthwhile. That evaluation, of whether it's actually worthwhile, will be an ongoing process. I'm certain that one of many factors in that evaluation will be "is this not just better, but substantially better, to the point that it's worth the expectation that kernel developers will have to deal with it in the kernel tree". That's a very reasonable question, and it's not one with a pre-determined answer.

Rust heads into the kernel?

Posted Apr 22, 2021 20:38 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

> Maintainability, with only 1% of kernel developers being able to review and fix that code instead of the previous 100% ?

Please don't just make up numbers. I wouldn't trust 100% of kernel developers reviewing sched, mm, rcu, or arch code because those domains are way more specific than just "it's C code, I'm a C programmer, I'll be fine". If maintainers of a domain don't want to learn Rust, then don't let it into your corner. Right now, it appears as though it will just be for device drivers. Over time, sure, maybe it'll do more. I don't forsee the wisdom of subsystem maintainers to all of a sudden being untrustworthy if introducing Rust into a corner is not actually ready (no different than any other patch that shows up).

> Portability, with a number of existing architectures not even being implemented by the language ?

The language supports it. The prevailing toolchain doesn't support every arch. There are those working on getting GCC to compile Rust which should resolve this issue.

Rust heads into the kernel?

Posted Apr 22, 2021 22:23 UTC (Thu) by josh (subscriber, #17465) [Link]

> There are those working on getting GCC to compile Rust which should resolve this issue.

There's also a project to use GCC as the code-generation backend for the existing frontend (which will avoid code duplication and divergence), as well as efforts to add LLVM backends for more architectures that people care about (there's now an m68k backend, so props to the m68k people for putting forth that effort).

Rust heads into the kernel?

Posted Apr 23, 2021 1:18 UTC (Fri) by roc (subscriber, #30627) [Link]

> Maintainability, with only 1% of kernel developers being able to review and fix that code instead of the previous 100% ?

If you think 99% of kernel developers will be unable or uninterested in learning Rust then you have dimmer view of kernel devs than I do.