Rust kernel policy

https://rust-for-linux.com/rust-kernel-policy

by LelouBil • 1 year ago

98 98 1 year ago

rust-for-linux.com

Deeg9rie9usi• 1 year ago

The CC list is interesting: https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...

sylware• 1 year ago

Please fix rust to make its toolchains statically link libgcc. Bug since 2015...

TheCleric2• 1 year ago

It’s all open source and therefore mostly unpaid volunteer driven, but it doesn’t really feel like there is truly a policy. Every week we see a story here about a kernel maintainer complaining about Rust and Linus refusing to actually apply any sort of rules to the maintainers.

It just seems very aimless and unfocused.

giancarlostoro• 1 year ago

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.

baq3• 1 year ago

Unfortunately it won’t matter if the C and only C developers block generic language interoperability interfaces…

geodel• 1 year ago

someone needs to step up and be the Linus of Rust code for Linux

No. Better to have just Linus for Rust. Write a new OS in Rust unencumbered by C curmudgeons. As a bonus it won't be thankless but pretty exciting project on work on.

fweimer2• 1 year ago

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.

TheCleric2• 1 year ago

I agree it’s no easy task. It seems to me though, as an outside observer, that writing virtually no enforced policy is the lazy way to go about it. Write a policy, stick to your guns, have a procedure for changing it if you get it wrong.

dyingkneepad• 1 year ago

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/

sunshowers• 1 year ago

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.

progmetaldev3• 1 year ago

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.

timeon2• 1 year ago

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).

This does not seems like arguing in a good faith. As example last 'drama' was explicitly about that PR with Rust code went into Rust branch not under C maintainer. Yet he blocked it anyway even when Rust maintainers stated, again, that any change in C API, that would break Rust code, was responsibility of Rust maintainers. Yet people (like you) are still ignoring this. Why?

bitwize• 1 year ago

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.

okanat3• 1 year ago

The people who contribute to kernel and especially maintain the subsystems are some of the most well-paid developers out there. If they are not a principal engineer somewhere, they have their own lucrative consultancy business.

fweimer2• 1 year ago

Probably more relevant are the Rust version policies: https://rust-for-linux.com/rust-version-policy And the policies around unstable Rust features (at least they are acknowledged as a problem): https://rust-for-linux.com/unstable-features

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). Some kernel developers are very much opposed to mixing GCC and Clang in a kernel build (to put it mildly), and some version combinations are known not to work. On the other hand, it seems somewhat unlikely that distributions would abandon building the kernel with GCC just to be able to use drivers written in Rust.

mustache_kimono2• 1 year ago

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.

rcxdude2• 1 year ago

It still does, no? Linux isn't written in standard C, it's just that clang caught up with gcc in extensions.

DSMan195276• 1 year ago

IMO you're comparing apples and oranges. The GNU C extensions are 'stable' when using GCC, they're just not part of the regular C language, plenty of them are still in wide use in the kernel. Unstable Rust features in comparison are explicitly in a state where they could be changed/broken or removed in any later release.

withinrafael• 1 year ago

Seems like a good tool for ensuring everyone is aligned.

Nit: The policy document seems inconsistent in its authoritative tone. In some sections, it hand-waves and punts to an external resource. For example: "Yes, there are key kernel maintainers who support Rust in the kernel. [Check out this PDF of keynote slides and figure it out yourself]."

okanat3• 1 year ago

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

mecsred• 1 year ago

I think the way it was handled is pretty reasonable considering it's a public facing statement. Putting your name down on an authoritative statement is an important commitment internally, but a name put down for any reason on a public statement is a magnet for a firehose of questions, controversy, and potentially harrassment.

bityard2• 1 year ago

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

layer8• 1 year ago

The question of who has the authority over the policies regarding the integration of Rust code into the kernel seems like a different question than who is maintaining Rust code.

hitekker3• 1 year ago

You’ve misunderstood the GP. He liked the post and offered one suggestion; your anger is misdirected.

HL33tibCe7• 1 year ago

I feel like Rust just isn’t stable or mature enough as a language for moving Linux towards it to make sense.

Currently feels like you need a PhD in programming languages to use it effectively. Feels like Haskell in many ways.

nightski• 1 year ago

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

itishappy• 1 year ago

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.

escobar_west• 1 year ago

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.

umanwizard2• 1 year ago

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

baq3• 1 year ago

I must protest - putting any language on par with C++ level of difficulty is unfair to C++. (Let's exclude malbolge and its relatives for a second)

dralley3• 1 year ago

With all due respect I question how much experience you actually have with Rust. It's nowhere close to being as difficult a language as you describe.

Rust got popular in part because it made systems programming easier, simpler and more fool-proof than the existing alternatives (C, C++) for those coming from languages like Python, Ruby and Java. As someone whose primary experience is in Python, I never found Rust abnormally difficult to pick up, whereas Haskell is (and remains) entirely alien to me. Sure, lifetimes can get messy, but it's much easier to have the compiler hit me on the head when I'm doing something dumb than to spend 2 days figuring out how to use Valgrind and the other half-dozen different static analyzers. I don't need to devote 100% of my mental effort to be able to write reliable code that's not going to blow up later in subtle ways.

zanellato19• 1 year ago

I feel crazy when I read comments like that about Rust. C is much, much harder than Rust. C is absolutely crazy difficult. Fairly simple to learn, but incredibly hard to actually write correctly. Rust is much, much easier. The learning curve isn't that hard. One week and you can be fairly productive with it.

timeon2• 1 year ago

Currently feels like you need a PhD in programming languages to use it effectively.

I've learned it because it was easier than C++ or even C. Yes you can learn C quickly, but you need much longer time than for rust to use it properly.

Also I do not have PhD not even CS degree and it was not hard. You should try it.

lukaslalinsky2• 1 year ago

I'm an outsider, only submitted one tiny patch years ago, but it seems like this Rust for Linux initiative will end badly if it's not stopped. You have so many people involved in work on this open source OS written in C and they will be pushed to accepting foreign code. 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?

zozbot2342• 1 year ago

We now have https://github.com/FractalFir/rustc_codegen_clr#c-support . So we can keep all our Rust files out-of-tree and just submit C code like everyone else.

michaelanckaert• 1 year ago

I can't image what reviewing C code like that would look like? Rust is a complex piece of technology, is the transpiled C code 'clean' enough to be able to review it?

kmeisthax2• 1 year ago

This violates the GPL.

paulddraper• 1 year ago

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.

estebank• 1 year ago

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

lukaslalinsky2• 1 year ago

Internal or external, it doesn't change much. Either Rust usage remains very isolated, or Rust takes Linux over and who doesn't want to deal with Rust should leave. Even the policy acknowledges, that the rust team being responsible for fixing broken rust builds is only temporary.

empath75• 1 year ago

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

varjag2• 1 year ago

Most people reading this will switch careers from IC before that happens.

criticalfault• 1 year ago

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.

motorest• 1 year ago

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?

0x4572• 1 year ago

I have work on such companies unless you count TypeScript and JavaScript as two languages.

Comment you're replying to is about some kernel developers not wanting to learn/write/use rust.

owl_vision2• 1 year ago

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

saagarjha3• 1 year ago

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?

kmeisthax2• 1 year ago

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.

sundarurfriend3• 1 year ago

The page uses "our" and "we" a bunch of times, but doesn't say who this "we" is. 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.

Which is fine, but then the document also doesn't cite most of the things it states, and isn't always clear on what's established fact/standard and what's this group's opinion. For eg.

Should maintainers treat Rust code up to the same standards?
Ideally, and eventually, yes. However, when they are starting out, not necessarily.

Sections like this have no indicator for whether this is opinion they are stating, an argument they're presenting, or an already-decided kernel policy that they're citing.

---

On the costs side, [...] most Rust language features we used were stabilized

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

steveklabnik4• 1 year ago

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.

curtis3389• 1 year ago

The Rust for Linux politics mess should be laid squarely at Linus' feet. He's the BDFL. He approved adding Rust to Linux, and he massively failed at communicating what that even meant. If he wants Rust in the kernel, he needs to kick some maintainers in the ass and get everyone aligned.

timewizard4• 1 year ago

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

rcxdude2• 1 year ago

He needs to say so before wasting everyone's time

arlort2• 1 year ago

I don't know enough to agree or disagree with the person you're replying to. But I assume the logic would be that if Linus doesn't approve then he should have shut the discussion down long ago or at least do it now without half measures

bastardoperator• 1 year ago

fork, runix? (/s?)

wavemode• 1 year ago

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.

godelski• 1 year ago

I think this is an important point. People believe "dictator" means "complete control" when instead "dictator" mean "authority to make any decision." The difference is exactly what you say, that you still have to rely on the hierarchical structure and trust that your "underlings" are making the right decisions. Complete control doesn't scale very well and even a small project or team has many moving parts and the only way to have full control is to be involved in every part. With scale, rapidly comes the necessity for trust. There's only so much time in a day, and only so much can be done in an hour. Damned physics, always getting in the way.

Brian_K_White• 1 year ago

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.

perching_aix• 1 year ago

"If he wants" != "he wants"

"He approved" != "He wants"

jcarrano2• 1 year ago

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?

dralley3• 1 year ago

FWIW, there are plenty of backchannels through which discussions about this stuff can be had that aren't the public mailing list. My limited understanding is that those discussions have in fact taken place and the R4L people aren't concerned about things working out eventually.

However, I do wish he would say something publicly, so that the internet peanut gallery doesn't fill the void with negativity. It doesn't exactly help attract more interest in the project.

owl_vision2• 1 year ago

Any doctrine similar somehow never made it, unless the prog lang is scheme or guile or racket but i consider Tcl a lisp in disguise.

andrewstuart• 1 year ago

My prediction:

Linus will retire and leave the Rust mess for other to live with.

dralley3• 1 year ago

The most likely replacement for Linus as BDFL is Greg KH, who is also friendly (if anything, friendlier) towards R4L.

hitekker3• 1 year ago

This answer seems like a big spin:

Is Rust for Linux driven by the "Rust community"?
No, the people involved around Rust for Linux come from different backgrounds and organizations. Some are kernel maintainers, some are Rust experts. Some are hobbyists, some are employees at large corporations
Particularly, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby, it is not an effort driven by the Rust Project nor the Rust Foundation. In fact, Rust for Linux was founded by a Linux kernel maintainer as a hobby

The Rust Project says R4L is a “flagship” goal: https://rust-lang.github.io/rust-project-goals/2024h2/goals.... I recall Josh Triplett saying R4L was a big priority for Rust this year; he pledged his support.

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

Edit: [1] see https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ...

sundarurfriend3• 1 year ago

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.

hitekker3• 1 year ago

Hey, good catch. I edited my comment to be clearer.

ojeda• 1 year ago

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.

JoshTriplett• 1 year ago

As Miguel said, the commitment from the Rust project is making Rust for Linux build on stable Rust, rather than using nightly. We care about that for a variety of reasons: we don't want folks to get a negative impression of Rust's stability based on nightly Rust, and Rust for Linux is a good exemplar of projects needing certain features, and it's an important effort in its own right that demonstrates the ability to incrementally add Rust to an established project.

It's up to the awesome Rust for Linux folks to work on the integration and upstreaming and policy needed to ship the kernel with Rust. And they're doing incredible work, based on the ability to write more and more kinds of drivers/filesystems/etc in Rust.

HarriL• 1 year ago

Summary: Why Rust Cannot Be Fully Integrated into the Linux Kernel

Rust-for-Linux (R4L) is an experiment, but it faces fundamental obstacles due to the Linux kernel’s monolithic structure, constantly changing APIs, reliance on GCC, and existing development model.

Key Challenges: 1. Unstable Kernel APIs – Linux kernel APIs frequently change, making Rust integration difficult without a stable ABI, which contradicts Linux’s development model. 2. GCC vs. LLVM Conflict – The Linux kernel primarily relies on GCC, while Rust requires LLVM. This creates fragmentation in the toolchain. 3. Dual-Language Complexity – Developers must master both C and Rust, leading to recruitment and maintenance challenges. 4. Memory Model Incompatibility – Rust’s ownership model does not align well with many kernel subsystems, requiring workarounds that reduce its safety benefits. 5. Monolithic Kernel Issues – Linux is designed as a monolith, where all components deeply interact. Introducing Rust without a complete rewrite results in complex dependencies and maintenance overhead.

Only Viable Solution: A Full Fork

A Rust-based kernel requires a complete fork from Linux, rewriting everything in Rust. However, such a project would no longer be Linux but an entirely new OS.

Thus, Rust cannot become a true part of the Linux kernel without fundamentally breaking its principles. The real question is: Should a new Rust-based OS replace Linux, or should Rust-for-Linux be abandoned?

Rust kernel policy

Related Stories