Behold, a Linux maintainer openly admitting to attempting to sabotage the entire Rust for Linux project:
https://lwn.net/ml/all/20250131075751.GA16720@lst.de/
The good news is this doesn't affect drm/asahi, our GPU driver. The bad news is it does affect all the other drivers we're (re)writing in Rust, two so far with a third one coming.
Another choice quote, calling R4L "cancer": https://lore.kernel.org/lkml/20250128092334.GA28548@lst.de/
Personally, I would consider this grounds for removal of Christoph from the Linux project on Code of Conduct violation grounds, but sadly I doubt much will happen other than draining a lot of people's energy and will to continue the project until Linus says "fuck you" or something.
As for how to move forward, if I were one of the Rust maintainers, I would just merge the patch (which does not touch code formally maintained by the dissenter). Either Linus takes the pull, and whatever Christoph says is irrelevant, or he doesn't, and R4L dies. Everything else is a waste of everyone's time and energy.
Edit: Sent in my 2 cents: https://lore.kernel.org/rust-for-linux/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/T/#m1944b6d485070970e359bbc7baa71b04c86a30af
In this thread, much the same as in any discussion of the topic, we learn that Rust is vital to the survival of the Linux kernel and we're surely doomed without it, and that the absence of languages other than C in the Linux kernel is the only thing preventing the demons of chaos from arising to tear our souls to shreds and we must remain pure.
looks like a lot of people want to die on the C programming hill. Cannot blame them, they have no will or ability to keep learning in an industry that *checks notes* ...asks you to keep learning!
C is much simpler from a language perspective. It doesn't have safety rails but it also has a lower learning curve assuming you understand computer hardware.
There are some warts of C that I feel Rust addresses very well. Mainly extensible type system that is not bad like C++. Secondly cargo. Building and packaging just feels wrong in C.
Only one place where C is still better than Rust: Rust does not have a well defined standard ABI. Hence every project compiles everything from source and link statically. Whereas with C we have a standard ABI that can allow for dynamic linking.
C is simpler in the way that a motorbike is simpler than a car. Simplicity isn't the only criterion or we would write everything in assembly which is really simple.
Assembly wouldn't be viable because it requires rewriting for every architecture, C is the closest to assembly there is while still working on all architectures.
I'm pretty sure Lisp and Forth are simpler than C.
Does the Linux Kernel use simple C though?
I think and assume they use enforced guidelines, custom types and tooling to make it workable. By that point C is no longer simple. You extended the language to make it safe, and ended up with the same complexity.
That's pretty much the impression I've been getting from following the whole thing very loosely.
Honestly both takes a bad. On the one hand you should be open to new idea but on the other it is wise to stick with old and tested.
Rust is still a lot newer and less well tested. It isn't going to replace C any time soon but it is cool that we have some Rust code in the kernel.
You mean old and known to cause endless security vulnerabilities.
Poorly written code causes security problems regardless. C code written these days follows proper security practices so it is less of an issue. Its the random code from 2005 you need to be worried about.
I'm very skeptical of sticking to "old and tested" without reasoning.
If you're talking about the implementation, if they're making changes it's no longer "well tested". If it's undocumented, it's not approachable. If you're talking about toolchain, if the old is unapproachable because of inherent toolchain barriers, and custom toolchain dialects, I think it's good to question.
There may also be something to say about them struggling to get new contributors and maintainers (from what I heard/read).