Comment by afr0ck
10 months ago
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.
OP said "As long as this is not delivered"
There is nothing to deliver that would satisfy this argument. Pretending like the disagreement is about a failure of the R4L folks to do "enough" when in fact there is nothing they could do is toxic behavior.
If you go back digging in the LKML archives, Christoph's initial response to Rust was more of a "let's prove it can be useful first with some drivers"
https://lore.kernel.org/lkml/YOVNJuA0ojmeLvKa@infradead.org/
https://lore.kernel.org/lkml/YOW2auE24e888TBE@infradead.org/
That has now been done. People (particularly Marcan) spent thousands of hours writing complex and highly functional drivers in Rust and proved out the viability, and now the goalposts are being moved.
R4L people are allowed to get upset about people playing lucy-with-the-football like this wasting their f***ing time.
1 reply →
> 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...
Many of them have, in fact, done all of those things, and have done them over a time horizon measured in years. Many of the R4L developers are paid by their employers specifically to work on R4L and can therefore be considered reasonably reliable and not drive-by contributors.
Many existing maintainers are not "general contributors"
It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do.
Christoph refused to take onboard a new maintainer. The fight from last August was about subsystem devs refusing to document the precise semantics of their C APIs. These are signs of fief-building that would be equally dangerous to the long-term health of the project if Rust was not involved whatsoever.
3 replies →
it's like saying to people that they cannot add for example npu subsystem to kernel because they should first work for 10 years in other subsystems like filesystems on with they know little about.
sound absurd? just replace subsystems in above with C/Rust and the rest is the same.
Folks that maintain rust are responsible for rust code, if they won't deliver what is needed, their rust subsystem will fail, not C codebase, so it's in their own interests to keep things smooth.
my feeling is that some people think that C is the elite language and rust is just something kids like to play with nowadays, they do not want learn why some folks like that language or what it even is about.
I think the same discussion is when Linux people hate systemd, they usually have single argument that it's agains Unix spirit and have no other arguments without understanding why other thinks may like that init system.
8 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.
That has already been the case with Asahi Linux - for years. It exists as a series of forked packages.
The thing is, you do still have to present a light at the end of the tunnel. If, after years of time investment and proven commitment, you're still being fed a bunch of non-technical BS excuses and roadblocks, people are going to start getting real upset.
However, it may only get merged in by being conceptually re-thought and reimplemented, like the Linux USB or KGI projects back in the day.
The general pushback for changes in Linux are against large impactful changes. They want your code to be small fixes they can fully understand, or drivers that can be excluded from the build system if they start to crash or aren't updated to a new API change.
You can't take a years-maintained external codebase and necessarily convert it to an incremental stream of small patches and optional features for upstream maintainers, unless you knew to impose that sort of restriction on yourself as a downstream maintainer.