During the whole month of February we were sharing various news about him case of problems and disagreements that have been generated in the Linux Kernel developer community for development in Rust.
Even Some of the heavyweights in the community have made their position known and worse still, some have resigned from their positions as maintainers within some of the Linux kernel subsystems.
Given this wave of discussions that seems to be getting out of control, Linus Torvalds has taken matters into his own hands. y has joined the discussion around to the resistance of some maintainers to the introduction of Rust in the Linux kernel.
According to Linus, no maintainer is forced to learn, use or even consider the code written in Rust if you don't want it, since they can continue working exclusively with C.
On Wednesday, February 19, 2025 at 22:42 PM, Christoph Hellwig wrote:
>
The document states that no subsystem is required to use Rust. That's proven.
> be wrong for Linus. And although you may not have known it when
> When you wrote the document, you absolutely did so by posting it on the list.I was hopeful and tried it, to see if this long thread would yield results.
into something constructive, but this seems to be going backwards (or at least
at least not forward).The fact is that the pull request you objected to DID NOT TOUCH THE DMA
LAYER AT ALL.He was literally just another user, in a completely separate situation.
subdirectory, that didn't change the code you maintain in any way,
shape or form.
However, if a maintainer decides not to get involved, he or she will also not have the opportunity to influence in the way it is developed, nor influencing how its external links are integrated into the code of its own subsystem.
Torvalds explained that those maintainers who are interested in moving forward with Rust will be able to participate in its development, influence the construction of bindings and help maintain the corresponding interfaces. Conversely, those who choose not to work with Rust will be protected from the problems that may arise during its use, but will also be excluded from influencing its evolution. This approach creates a kind of barrier that, while protecting those who dedicate themselves exclusively to C, simultaneously prevents them from contributing to improving Rust's integration.
So this email is not about any "Rust policy." This email is about a
A much bigger problem: as a maintainer, you are in charge of your code,
Sure, but you're not in charge of who uses the end result and how.You don't have to like Rust. You don't have to care about him. That's it...
It has been made quite clear from the beginning that no one is
forced to suddenly have to learn a new language, and that people who
If you want to work exclusively on the C side, you can continue to do so.
This situation creates, in a way, a protective barrier.for those who work only with C, isolating them from the complexities and potential drawbacks associated with it to the Rust code. But at the same time, that same isolation prevents them from influencing Rust's progress, which means that the "no one has to deal with Rust" motto doesn't allow every maintainer to lock down any code written in this language.
La division of responsibilities is organized so those interested in Rust can work on its aspects, while those who choose not to get involved will not be forced to change their workflow, although they will not be able to modify the development of components written in Rust.
The controversy intensified when the issue of Rust binding approval via the DMA subsystem arose. In this case, the opposition of a maintainer attempting to block the acceptance of such bindings was ignored, and Linus openly criticized Christoph Hellwig's actions.
According to Torvalds, Hellwig had exceeded his authority. by trying to influence code that, being implemented in a separate subdirectory, didn't affect the DMA subsystem for which he was responsible. In Torvalds' words, Hellwig's attitude is akin to trying to disable DMA in a driver simply because he didn't like it, which is unacceptable.
Ultimately, although each maintainer is responsible for their own code, they cannot be required to control how that code is used or decide on its integration into larger projects.