Comment by Ar-Curunir
10 months ago
How many times will this need to be said: the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.
As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes:
https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...
> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.
> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".
> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.
For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?
> For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?
Yes actually, I really wish someone would bring that sort of thing to the forefront, because that's a great spot to welcome new contributors.
They've said that, but nobody believes them, and can you blame them given we JUST saw another big rust maintainer resign?
I'd be suspicious these guys aren't in it for the long haul if they don't get their way and will leave the Rust they shoved in the kernel to bit rot if things don't go their way w.r.t enough rust adoption fast enough. "If you don't let us add even more rust, we will resign from the project and leave you to maintain the rust that's already there and that we added, and that you said you didn't want to add because you didn't trust us to not resign".
Rust 4 Linux people just proving the points of the maintainers scared of abandonment.
The rust 4 Linux people unfortunarely give the impression of caring more about rust than about the kernel, and it's clear that many are willing to make that perfectly clear by abandoning the larger project.
The whole thing needs to be scrapped and rethought with better and more committed leadership. This past 6 months to a year has been embarrassing and done nothing but confirm the fears of anti rust people.
These people were quitting after being harassed. So I do not think you are arguing in good faith.
This is not what the "Rust kernel policy" [1] of Rust for Linux says.
[1]: https://rust-for-linux.com/rust-kernel-policy
> 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.
> Didn't you promise Rust wouldn't be extra work for maintainers?
> No, we did not. Since the very beginning, we acknowledged the costs and risks a second language introduces.
You conveniently left out
> 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.
Yes, "breakage should be fixed as soon as possible". Not "Rust for Linux team will fix the breakage as soon as possible".
The exception is allowing the subsystem to break Rust code temporarily. If you accept a patch in C that breaks Rust code, and the Rust for Linux team doesn't fix it quickly enough, you either need to fix the Rust code yourself, remove it, or re-write it in C. All of this would take time and energy from all the non-R4L kernel devs.
This is why people are reluctant to accept too much mixing of the C and Rust codebases, because even the Rust for Linux team isn't promising to fix breakages in Rust for Linux code.
5 replies →
This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.
At some level this is just concern trolling. There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just expressed. You are asking for something that is impossible.
What could they possibly "deliver" beyond a strong commitment to fix the code in a timely manner themselves?
It is not concern trolling. It is a harsh disagreement.
Some kernel developers really do feel that any Rust in the kernel will eventually mean that Rust gets accepted as a kernel language, and that they will eventually have to support it, and they the only way to prevent this is to stop any Rust development right now.
And yes, there's nothing that the R4L group can offer to be get around that belief. There isn't any compromise on this. Either Rust is tried, then spreads, then is accepted, or it's snuffed out right now.
A big mistake by R4L people is seeing anti-Rust arguments as "unfair" and "nontechnical." But it is a highly technical argument about the health of the project (though sometimes wrapped in abusive language). Rust is very scary, and calling out scared people as being unfair is not effective.
2 replies →
> There is nothing the Rust developers could possibly do or say that would alleviate the concern you've just exprssed.
They could do exactly what Ted Ts'o suggested in his email [1] that Marcan cited: They could integrate more into the existing kernel-development community, contribute to Linux in general, not just in relation to their pet projects, and over time earn trust that, when they make promises with long time horizons, they can actually keep them. Because, if they can't keep those promises, whoever lets their code into the kernel ends up having to keep their promises for them.
[1] https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.ed...
13 replies →
To start, not resigning when things don't go their way. That tendency is doing a lot to make the claim of rust people saying they will handle the burden of rust code unbelievable.
The standard procedure is to maintain a fork/patchset that does what you want and you maintain it for years proving that you will do the work you committed to.
Once it’s been around long enough, it has a much better chance of being merged to main.
2 replies →
As a non-interested observer; I think it will need to be said until the commitment becomes credible. I don't know how it would become credible, but it's clearly not considered credible by at least those of the kernel maintainers who are worried about the maintenance burden of accepting rust patches.
That doesn't line with https://rust-for-linux.com/rust-kernel-policy#who-is-respons... (which may be a recent change?)
I don't think it is this simple.
> the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side.
How have they "committed"? By saying they commit[1], I presume -- but what more? Anyone can say anything. I think what makes the "old guard" kernel maintainers nervous is the lack of a track record.
And yes, I know that's a kind of a lifting-yourself-by-your-bootstraps problem. And no, I don't know of any solution to that. But I do know that, like baron Münchhausen, you can't ride your high horse around the swamp before you've pulled your self out of it.
___
[1]: And, as others in this thread have shown, that's apparently just out of one side of their collective mouth: The official "Rust kernel policy" says otherwise.