"Torvalds said that it is not necessary to understand Rust to let it into a subsystem; after all, he said, nobody understands the memory-management subsystem, but everybody is able to work with it."

Chuckled a bit at this line, anyone have context on how true this is?

Aside: LWN is basically what ChatGPT summarization as advertised itself to be, except it's actually good and coherent and useful. I can trust Jonathan to summarize the conversation in a way that is mostly sane and reasonable in a way that I can never hand off the job to generative AI. It's an important area where humans seem to excel over computers.

Also, just to have some content that is actually on-topic: is anyone actually shipping upstream Linux Rust code yet? I understand that some stuff is slowly merging in but I'm not sure if it's actually being exercised yet.

On a semi-tangent, does anyone happen to know how Microsofts push to use Rust in the Windows kernel is coming along? They rewrote some components in Rust and rolled them out to production about a year ago but it has seemed pretty quiet on that front since then, unless I missed something.

>Changing C interfaces will often have implications for the Rust code and may break it; somebody will the have to fix the problems. Torvalds said that, for now, breaking the Rust code is permissible, but that will change at some point in the future.

I think this is the main technical change needed from the Linux kernel. It needs a layer of quasi-stable well documented subsystem APIs, which ideally would be "inherently safe" or at least have clear safe usage contracts. And it's fine for these interfaces to have relaxed stability guarantees in the early (pre-1.0, if you will) experimental stages. Changing them would involve more work and synchronization (C maintainers would not be able to quickly "refactor" these parts), but it's a familiar problem for many large projects.

It's the only reasonable point from the infamous tantrum by Ted Ts'o during the Rust for filesystems talk, everything else, to put it mildly, was a really disappointing behavior from a Linux subsystem maintainer.

Thought that ThePrimeTime in his video https://youtu.be/62oTu9hjxL4?si=E98WZ0zJSNUC8TEH&t=287 hit the nail on the head re: Rust versus C.

Max level C programmers, have designed their programming style around control down to the absolute bit. C derives control from absolute control over behavior.

Max level Rust programmers have complete mastery of types. Rust derives control from types.

Seems somewhat philosophically incompatible.

Can anyone explain to me why these two issues aren't considered deal breakers for introducing Rust into the kernel?

1. It doesn't map almost 1:1 to assembly the way C does, so it's not inherently clear if the code will necessarily do what it says it does. That seems questionable for something as important as a kernel and driver.

2. Only one real Rust compiler, that's a recursive compiler, which reminds me of the Trusting Trust problem: https://dl.acm.org/doi/abs/10.1145/358198.358210

Even though I don't use Linux in my projects, Rust on Linux is extremely important to convince others to use Rust. I hope it succeeds.

Not exactly rust-in-kernel, but I've been using Aya[0] to write ebpf programs in Rust and it is quite nice. The verifier is still a bit trigger-happy with some constructs, but it is manageable.

[0]: https://aya-rs.dev/

Totally unrelated comment to my previous one

I think it's folly to encode the semantics of APIs in the Rust type system and memory model and that's the impedance mismatch that has people riled up. unsafe code isn't incorrect code, and trying to add abstraction where there wasn't one before is encoding principles where they didn't previously exist and should be an obvious problem.

I've written a lot of systems-type Rust using unsafe and I think the design pattern of -sys bindings and then a higher level safe wrapper is mostly incorrect because callers should always use the -sys bindings directly. It's more workable and doesn't suffer from changes that the detractors complain about.

What is the value in relying on distro authors to publish rust compiler versions, when the bespoke release channel for rustc is kept much more up to date?

Does Rust support the same range of architectures as C? Or is there some way to compile Rust to C to support weird obscure systems?

Forgive me if this is something commonly known by the people involved. It just strikes me as the most obvious objection to Rust in the kernel and I haven't seen any explanation of what's going to happen.

As a side note, does anyone know what the backup plan is if Linus is suddenly no longer able to lead in his current capacity? I think it's likely there is one, but am not sure what it is.

Regardless of what upstream decides, downstream on ChromeOS and Android land, it is already being used.

I’ve read many times that a goal is to see if the use of Rust can work out in the kernel.

What does this experiment for? What exactly is the evaluation? What are some example findings, both pro and con?

Why can't all symbols exported to modules maintain a C ABI, obviating (if I understand correctly) the genksyms problem?

> he also is unable to work with Rust until a suitable compiler is available in RHEL

What an arse. Best to ignore these people.

[flagged]

With the Rust team falling apart, who is actually long term going to maintain it? I want to use it but I just see drama.