It just seems very aimless and unfocused.
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/
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.
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?
Subject: Re: [PATCH v8 2/2] rust: add dma coherent allocator abstraction. https://lwn.net/ml/all/20250108135951.GA18074@lst.de/
I believe there is a middle ground where everyone can be happy, and firmly believe that the Rust maintainers in the Linux project will keep on top of the C interfaces to know when there will be changes. Going back to my comment, I realize that I presented why the C developer/maintainers don't want Rust, but that is not my own stance. In my opinion, there is enough interest in the Rust for Linux project that acting as though there is only a single maintainer, and if they disappear the entire project fails and all Rust code stops compiling is unrealistic and FUD.
I can see a whole host of problems being tackled, especially in driver development and safety concerns, by using Rust. I feel the C maintainers are acting as if the entire kernel is going to be rewritten in Rust in a timeframe where any of these people would still even be capable of using a keyboard or not suffering from severe dementia.
My apologies to anyone that thought I was pushing for one side or the other, I was only repeating the recent "drama" that I heard was going on, and I respect both sides.
Writing policies hard, and the environment here is somewhat challenging.
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.
The problem with this direction is it dooms Linux to obsolescence. Thanks to Rust's memory safety, Redox has achieved a level of security and crash-resistance that Linux cannot hope to achieve with C. With everyone (including the US Govt) pushing for memory safe code, this has a negative impact on the whole world's major investments into Linux.
To mitigate the sunk costs, Linux needs to compete on memory safety. C has no viable solution so Rust is the only option.
Isn't Zig designed as a viable solution? IIRC being easily compatible with C is one of its features.
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.