Rust kernel policy

To play (BDFL's) advocate - Linux is an -enornous- project. It's not physically possible for any effort to be unilaterally directed. Linus does not personally maintain the whole thing, it's just not possible. So he has maintainers under him who are in charge of the subsystems - the implication being that he trusts their judgment and technical expertise. There's no other way the system could work, really.

Linus's position, as far as I've heard and ascertained, is that introducing any language into the kernel is going to require case-by-case and subsystem-by-subsystem analyses. He's not going to reject the language wholesale, but at the same time it's impossible for him to wholesale mandate its adoption. "Kicking maintainers in the ass" sounds great but nothing is ever that simple.

Why do you assume he either wants it or doesn't want it?

The only way I ever interpreted his actions so far is he's willing to allow those who want to try.

And I see nothing unreasonable and no failure in that. It is a hashing out process, in process.

Either he failed at communicating, or he does not care. Reading the recent thread/flamewar on R4L and DRM I wonder if he was somewhat pressured to accept Rust but does not actually care. If you were the leader of a project and explicitly authorized a sub-project, would you tolerate a maintainer undermining it?

And if he doesn't want it in the kernel?

> Wait a second, that’s not what this page says: https://rust-lang.github.io/rust-project-goals/2024h2/goals....

I don't understand what you're saying - is your point that having Goals means that this can no longer be considered a hobby? Lots of people have hobbies where they have goals for a sense of direction and satisfaction. (Not to mention that the page doesn't say it is a hobby, just that it was started as one.)

> Also, didn’t the author resign from this effort before? Or was that departure not as dramatic as I recall.

Who do you mean by "the author" here? This seems to be a group effort by a "Rust for Linux" group, not a single individual.

> The Rust Project says R4L is a “flagship” goal

Rust's 2024H2 and 2025H1 flagship goals are about getting Rust for Linux into stable Rust, implementing features we need and so on. We really appreciate being a flagship goal of theirs! We collaborate regularly, and some members are part of both projects, and so on and so forth.

But that does not mean one is driven by the other, just like GCC and Clang do not drive the Linux kernel because they introduced features to build it. They support us, which is different.

> Also, didn’t the author of this updated doc (Miguel Ojeda[1]) resign from R4L? I’m not sure what his role is here.

I wrote the document, but I never resigned since I started the project -- you are probably referring to Wedson. I have seen articles that confused both of us in the past, so that is not a surprise, though I wouldn't mind to have Wedson's mind around from time to time :)

The FOSDEM 2025 keynote has some details about the history of the project. There is an LWN article about it: https://lwn.net/Articles/1007921/

I hope that clarifies.

> The implication from the "Contact" page seems to be that this is some "Rust for Linux" group that may or may not be well defined.

It says:

> For other matters, please feel free to contact the maintainers via email.

Which links to https://docs.kernel.org/process/maintainers.html#rust which has a list of people.

There is also https://github.com/Rust-for-Linux/linux/blob/rust-next/MAINT... which is the in-tree documentation of who maintainers are.

> The fact that this has to be specified - and still qualified with "most" - is a big part of the problem with this.

For a very long time, linux wouldn't even compile with clang, becuase they use gcc extensions. These are effectively the same idea as nightly features. The kernel has never used standard C. Nowadays clang has enough support and keeps it going.

I agree with you that I personally would much prefer that they were on 100% stable Rust, but the Linux folks in general are way more fine with depending on specific versions for the build.

> They don't say what their policy is regarding building the C parts with GCC and the Rust parts with the LLVM toolchain (including the Clang parts that bindgen uses).

My understanding is this concern was broached very early in the Rust for Linux project and Greg Kroah Hartman explicitly signed off on "building the C parts with GCC and the Rust parts with the LLVM toolchain". See: https://news.ycombinator.com/item?id=24335831 and https://lwn.net/Articles/829858/

> And the policies around unstable Rust features (at least they are acknowledged as a problem):

I am amazed at what short memories many have. I remember when clang couldn't build the kernel. I remember when GCC required many special extensions to the C language to even compile the kernel. I think GCC may still require some of these and clang/LLVM may require emulation of the same.

Now, Rust gets the surprise news they may be included in the kernel and they have worked diligently to stabilize certain unstable features. Can you imagine what kind of rudder movement something similar would take to turn the C/C++ committees/tankers? Obviously, language "stability" isn't the issue you make it out to be, because, for decades, the Linux kernel required GCC extensions.

Would YOU want to be named (without permission) in a document like this as being responsible for something in a high-visibility project like the kernel just because you contributed some code, or gave a talk at a conference?

Anyway, some slides at a conference are not the authoritative source for who works on Rust in the Linux kernel, something this is:

grep -i rust MAINTAINERS

Yeah. This answer is weak. If they are really supportive, they need to put down their names.

Are you aware that RfL is not outsider Rust enthusiasts pushing on the kernel, but rather existing Linux kernel developers wanting to use Rust?

There were also a lot of times mentioned that current maintainers are getting old. Rust people might, with time, take over... being younger and all.

Rust was specifically designed to integrate well into a C codebase; and Rust for Linux was specifically for drivers - not to replace all of Linux's internals.

The two things that putting Rust in Linux actually requires of existing C maintainers is:

- They have to not get in the way of Rust bindings

- They have to document critical pre- and post-conditions of their code that impact memory safety

That last one is a problem - not one that Rust caused, but a problem that's been in Linux nonetheless. This is the thing that all the BSDs hate on Linux for. Typically, the approach to handling big breaking changes with Linux kernel objects is "make it compile, then change all the things that crash until they stop crashing". This means there isn't any documentation to write safe bindings for any Linux kernel function, since it could, say, rely on you calling three other functions in a specific order that just so happens to match the one major driver that uses that subsystem[0]. For Rust bindings to make sense and actually provide value, the subsystem maintainers need to provide documentation that they usually don't bother with.

The first one on the list is the reason why Hector Martin ragequit his maintainer position and decided upstreaming Asahi drivers isn't worth doing. There's a few subsystem maintainers that internally decided "I don't care what Linus thinks, fuck Rust". One of them happens to be the maintainer for the DMA subsystem, which happens to be... fairly critical to writing any non-toy driver.

The problem is specifically that there isn't a push for Rust. Linus is uncharacteristically fence-sitting here, to the point where people are writing Rust drivers that can't be upstreamed because his own maintainers are blocking them. Having the kernel support two languages is fine, but it requires Linus actually put his foot down and either say "stop treating the Rust people like Nvidia and let them write safe bindings to kernel internals," or, "we're not going to do Rust at all because of X, Y, or Z."

[0] I am told amdgpu is like this.

> Rust, as a very complex and opinionated language, is not an easy choice to accept for C developers. If the push continues, maybe we will see the existing maintainers leaving?

What are you talking about? I'm yet to work at a business where developers aren't proficient in 2 or more programming languages. Why do you presume that experts in the field would be blocked by a limitation that does not apply to the vast majority of professional software developers?

Every other engineering organization on the planet seems to do just fine with a polyglot codebase. Do you really think kernel maintainers are dumber than the average Google engineer?

Eventually, there are going to be more experienced Rust developers than there are experienced C developers.

> maybe we will see the existing maintainers leaving

That is probably true.

The reasons for Rust are compelling. And the uncountable value of the Linux kernel justifies a lot of pain.

and eventually create this totally new language full of certainty and more...

Kernel programming is probably one area you don’t need to optimize for newbie programmers to jump in like the web

I'm not sure lowering the barrier to contribute Linux kernel code is a great argument for C. It sounds like contributing code that doesn't segfault often still requires a PhD.

Rust and Haskell are difficult for completely different reasons. Rust is difficult for roughly the same reasons C++ is difficult.

Rust and Haskell are completely different languages so I don't really agree here. Haskell doesn't have the features (lifetimes, ownership) that make Rust "hard" and Rust lets you have mutable states and procedural code.

Rust is also quite stable and mature by now, I'm not sure what example or reason you're using to say otherwise.

> It’s all open source and therefore mostly unpaid volunteer driven

The vast vast vast majority of Kernel development (and, I would guess, low-level open source software development) is paid for by companies.

Here's an example. Scroll down to "Most active 6.13 employers". Unknown+None is not even 15%: https://lwn.net/Articles/1004998/

I personally think Linus is making the right choice here, and not explicitly denying Rust in the kernel. Instead he is delegating it to other high level maintainers to work out the issues and make the decisions on how the integration will go. He is already so heavily involved in day to day operations in the C code, I can't imagine him being able to take on the burden of also needing to negotiate pulling in an entirely new language.

From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code).

I am not for or against Rust being in the kernel, but I can appreciate the view of maintainers on a project of this age being concerned about introducing a second language (one which many of the C developers are not familiar with). This isn't a single company's web application project where a polyglot environment should work well when chosen for the right reasons. The Linux kernel is a backbone of modern computing, and making a decision on what to do without exploring all potential benefits and issues would be irresponsible at best. From what I've read, the Rust proponents want a piece of Rust middleware for DMA access so that each rust component doesn't need to have their own implementation, but the C maintainers don't wish to have to maintain C interface compatibility for Rust. With Linus stating that all code in the project must compile to be accepted in a release, this puts a heavy burden on the C maintainers where they are now required to work with the Rust developers fairly closely. Some of these maintainers have been around for a long time, and are skilled in C and do not wish to learn a new language for when the shit hits the fan and something in the Rust code breaks.

Again, this is just my understanding of the situation from what I've read, I may have some of this completely wrong, and if so I apologize to anyone involved.

It's not that it's volunteer driven (which it is not, as the siblings have pointed out), it's that it's distributed governance without the central authority enforcing a vision.

Most development in this space (toolchain and kernel) is funded in some way. I don't know if this particular project is at some strange intersection where this isn't the case, but I would be surprised.

Writing policies hard, and the environment here is somewhat challenging.

My guess is someone needs to step up and be the Linus of Rust code for Linux. It's the kind of thankless task that is invaluable, whoever can muster the courage to do it will be vital to Linux/Rust.

Despite starting off "not big and professional like gnu" Linux now has trillions of dollars' worth of business going over IT infrastructure based on it. You bet your ass it's a corporate funded behemoth now, not unpaid volunteer driven. And with corporate money comes corporate governance. Ouster of Linus as the chief maintainer is definitely on the table (though not likely to ve exercised here and now). I think Linus is being wishy-washy so as not to anger either the traditional "C-niles" currently holding the kernel together or the Rust group, who are likely a more prolific source of new development.

The right call here is to tell Ted Ts'o and the other old guard that they need to adjust to the new Rust reality, because things like being explicit about object lifetimes will make the C code better as well as more compatible with what the Rust side wants to do. But he either doesn't want to do that or is looking for a diplomatic way to go about it.