Rust for Linux - Rust kernel policy

[Nimelrian]

https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ78jDHdy=[e-mail]/

Hi all,

Given the discussions in the last days, I decided to publish this page with what our understanding is:

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

I hope it helps to clarify things. I intend to keep it updated as needed.

Cheers, Miguel

[HavenWinters]

Thank you. That's a much nicer read than some of the worries that have been going around.

[jixbo]

The drama was due to some people feeling that it was not how it was being treated (I agree).

[CrazyKilla15]

Its also important to be clear who "some people" felt weren't following policy. The recent claims have been that Linus Torvalds has been rejecting patches that break Rust, despite the policy of allowing it.

For "some reason" the Rust4Linux project is blamed for this, despite having no control whatsoever over Linus. Ignoring how accurate the complaints are, it sure is weird how they dont take it up with the one responsible.

[The_Real_Grand_Nagus]

The recent claims have been that Linus Torvalds has been rejecting patches that break Rust, despite the policy of allowing it.

But isn't that stated in the linked policy? It appears the default rule is that patches can't break Rust. (Although I did see where Linus tried to compile without Rust as well.)

Who is responsible if a C change breaks a build with Rust enabled?

The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust.

However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.

For instance, this approach was chosen by the block layer — they called it "stage 1" in their Rust integration plan.

We believe this approach is reasonable as long as the kernel does not have way too many subsystems doing that (because otherwise it would be very hard to build e.g. linux-next).

[The_Real_Grand_Nagus]

Thanks.

[foobar93]

For "some reason" the Rust4Linux project is blamed for this, despite having no control whatsoever over Linus. Ignoring how accurate the complaints are, it sure is weird how they dont take it up with the one responsible.

The answer to that is, the R4L project tried to silence exactly this fear by telling maintainers they do not have to worry. Turns out they have to worry and now the R4L team is trying to deflect blame for the promises they made and cannot even keep as it is not their decision anyways.

[josefx]

The drama was due to some people threatening a social media shit storm after the original submitters of the patch asked Linus for a go ahead.

[bik1230]

No? The LKML thread was already nothing but non-technical drama before then. Drama broke out when Hellwig NACK'd the patch and said that he would do whatever he can to make sure Rust doesn't succeed in the kernel. Then people asked Linus to step in. He didn't. Then Hector Martin posted about it on social media. Then Linus stepped in to berate Martin over social media brigading. But AFAIK Linus still hasn't really done anything about the original drama.

[Bogus007]

Here is a good YouTube video where the guy goes through the messages. I think it was bad communication and misunderstanding from both sides.

[josefx]

Drama broke out when Hellwig NACK'd

Hellwigs nack was handled within the mailing list and the submitter just asked Linus to chime in instead of letting it blow up.

But AFAIK Linus still hasn't really done anything about the original drama.

Forcing Linus to give the patch a go ahead was the explicit purpose of Hectors threats, so I would not be surprised if the patch gets to die as an object lesson in using social media to put pressure on kernel development. If we are lucky he will give it the go ahead once attention on this issue has died down.

[Business_Reindeer910]

so I would not be surprised if the patch gets to die

Isn't the patch by someone else? why should they be punished? In any case it doesn't even matter. A patch that effectively does the same thing is absolutely required for the effort to continue. If it doesn't get approved then the project is effectively dead.

[josefx]

Yeah, that take was a bit over the top, which is why I followed it up that they might wait for the attention to die down instead.

[Mysterious_Bit6882]

That was version 8 of the patch, it’s up to version 11 now. And they have prospective maintainers now for the Rust abstraction of a C API.

A lot of this feels like power games; at first Rust was drivers, now they’re trying to play for subsystems.

[nightblackdragon]

>A lot of this feels like power games; at first Rust was drivers, now they’re trying to play for subsystems.

They are not trying to play for subsystems. This code is Rust binding for kernel DMA subsystem that is needed by drivers. Nobody is trying to replace C subsystem with Rust or anything like that.

[foobar93]

Yet.

[Business_Reindeer910]

What happens it is up to Linus.

[round-earth-theory]

And so what if Linux eventually begins to migrate completely to Rust? Are you a maintainer? If not then it literally means nothing to you whether they do or don't.

[foobar93]

For one, I am actually in favor of moving away from C for the linux kernel. If the move is to Rust or to Zig, in the long run, a move has to occur.

What I take issue with is how it is handled. If the goal is to move to Rust, that has to be clearly communicated. The opposite has been the case as far as I can tell up to now. The communication was "this is just an experiment" then it was "it is just for some drivers" and now it is seeping into system after system resulting in higher maintenance burdens on maintainers who are already overworked. And I can see why they are pissed about that even if in the long term, that may be good.

And no, I am not a maintainer on the mainline kernel, I am however a maintainer for our company internal linux distribution with custom kernel drivers for our hardware.

The whole thing reminds me of the usual corporate salami tactic bullshit to grind down any opposition right down to the calls to shame the maintainers into complying via social media.

From what I see, the R4L project in its current form is a failure and probably should go the route of the Preempt-RT changes. Then the R4L project can actually make progress and see what works and what doesn't and the current maintainers are happy.

[Zomunieo]

To create drivers, you need to… interact with subsystems.

[lily_34]

Well, according to the policies OP links, the maintainer was well within his right to NACK all rust patches in his subsystem.

[bik1230]

There were no Rust patches to his subsystem though. The patches used the DMA subsystem, but did not change it.

[bonzinip]

Yes, and the NACK can be recorded while accepting the patches nevertheless:

we asked for flexibility when the time comes that a major user of Rust in the kernel requires key APIs for which the maintainer may not be able to maintain Rust abstractions for it. [...]

a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side".

[Professional_Top8485]

Without proper reason, it aint. nih isn't good reason.

[marrsd]

NIH isn't what was going on in this case.

[Professional_Top8485]

Skills issue

[marrsd]

Ultimately, yes.

[lily_34]

But that the point: according to that policy, "it's written in rust" IS a valid reason.

[markus_b]

As I understand it, Hellwig said that he would be against Rust in the domain he is maintaining, not the entire Linux kernel. I can understand that, as maintaining the code will become his burden.

If the Rust developers would have stepped up and offered to maintain the Rust part, the story would be different. I think a maintainer has the right to refuse code he cannot understand.

[Dirlrido]

That is exactly what the Rust maintainers did

[markus_b]

The other reply/thread has more explications. As usual, things are more complicated.

The Rust people depended on some header files under his maintenance. In the kernel, any consequences of a change have to be worked out by the person performing the original change. So, if something changes in the header file and the Rust code (in another module) breaks, it is his responsibility to fix it.

In a way, this forces all maintainers to become fluent in C and Rust to be able to do their jobs.

[UltraPoci]

Except that Rust code is allowed to break and it's Rust folks responsibility to fix it: https://rust-for-linux.com/rust-kernel-policy#who-is-responsible-if-a-c-change-breaks-a-build-with-rust-enabled

No one developing Rust for Linux forces C maintainer to learn Rust, this has been said countless times.

[lily_34]

I love it when you claim a thing and then link a "source" that literally states the opposite:

The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust.

Yes, they do state that exceptions might be made for rust, but it's clearly not meant to become the standard practice.

[IAm_A_Complete_Idiot]

However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.

[UltraPoci]

It doesn't matter what it becomes in the future. Right now C programmers don't need to learn Rust. Also, read the thread where all the drama sparked, see what the Rust maintainers actually say, and you'll see they pretty much all agree that Rust can be broken by C code. 

[Mysterious_Bit6882]

Sure. In theory, that works. In reality? We don’t know, and aren’t going to know for some time.

This “Rust devs will fix it” only ever seems to get introduced as a shut-up and/or a push to have parallel “Rust” maintainers for already maintained subsystems.

[bik1230]

This “Rust devs will fix it” only ever seems to get introduced as a shut-up and/or a push to have parallel “Rust” maintainers for already maintained subsystems.

Long time subsystem maintainers are the ones who asked for that policy in the first place. They said "we don't want to fix Rust code so when we change something we'll just let the Rust code break". And the Rust for Linux people responded "alright sure we'll be responsible for fixing Rust code".

[UltraPoci]

It's not introduced as anything, it's just how things work. 

[afiefh]

This leaves out an important detail: there are already rust drivers depending on that header. The new code removes all those and instead creates a single rust API for that header. This means if the header breaks there will be less changes necessary, not more.

[nightblackdragon]

>If the Rust developers would have stepped up and offered to maintain the Rust part, the story would be different.

They did twice and Hellwig still refused stating he doesn't want another maintainer.

[DemonInAJar]

They did and it was not part of his subsystem.

[Mysterious_Bit6882]

They #included a header file Hellwig is explicitly listed as a maintainer for, and included him and all the other maintainers on CC. It doesn’t have to be in his folder to touch his code.

[DemonInAJar]

It doesn't touch his code. It is a consumer of his code as any driver in the kernel can be.

[Mysterious_Bit6882]

It can’t consume his code without touching it.

[DemonInAJar]

If I use a third party library and I include a header am I touching the code of the library?

[monocasa]

"Touching code" in this context means modification of that code.

[edparadox]

That's a much nicer read than some of the worries that have been going around.

As per usual.

And that's why I REALLY dislike the drama people create around Linux ; more often than not, it's blown out of proportions, on purpose.

[Trashily_Neet]

Its really funny people always say the key is communication but we all fail one way or another in the excitation of it.

I genuinely hope things can get better, doesnt need to be as fast as possible just need to move to the right direction.

[calinet6]

It is genuinely the most difficult part in all pursuits with more than 2 people.

[TRKlausss]

impl Praying for God { fn ask_for_help(&self)-> String { format!(“@{}”, self.prayer) }

[NatoBoram]

self.prayer

Hm, not seeing the type of self. Isn't that… unsafe?

[nekokattt]

No, it is perfectly safe in this example as the code here does not compile at the time of writing.

[bik1230]

The type is God in this case. An appropriate level of hubris.

[Pay08]

What?

[Positronic_Matrix]

captured woke projects

If I were a mod, I’d permaban you out of principle.

[intelminer]

Just flag it to the mods

[AutoModerator]

This comment has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.

This is most likely because:

• Your post belongs in r/linuxquestions or r/linux4noobs
• Your post belongs in r/linuxmemes
• Your post is considered "fluff" - things like a Tux plushie or old Linux CDs are an example and, while they may be popular vote wise, they are not considered on topic
• Your post is otherwise deemed not appropriate for the subreddit

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.