{"id":122006,"date":"2025-02-19T14:22:14","date_gmt":"2025-02-19T12:22:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/linus-torvalds-nameren-vklyuchat-svyazannye-s-rust-izmeneniya-v-obhod-mejntejnerov"},"modified":"2025-02-19T14:22:14","modified_gmt":"2025-02-19T12:22:14","slug":"linus-torvalds-nameren-vklyuchat-svyazannye-s-rust-izmeneniya-v-obhod-mejntejnerov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/linus-torvalds-nameren-vklyuchat-svyazannye-s-rust-izmeneniya-v-obhod-mejntejnerov","title":{"rendered":"Linus Torvalds intends to include Rust-related changes bypassing maintainers","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Christoph Hellwig, maintainer of the DMA subsystem, KVM, Slab Allocator, and PowerPC architecture in the Linux kernel, has fundamentally refused to accept Rust bindings for the DMA subsystem into the kernel. He joined the discussion on the rules for maintaining Rust as part of the kernel, published by the Rust for Linux project. According to Christoph, such rules are useless until they are agreed upon with the community and included in the kernel documentation. <\/p>\n
Christoph also pointed out that the rules contain incorrect information regarding maintainers' ability to make independent decisions about including Rust-related code in their subsystems. Christoph stated that in a personal conversation, Linus Torvalds firmly expressed his intention to accept Rust code into the kernel despite maintainers' objections. Thus, developers and kernel maintainers will now have to deal with Rust, whether they want to or not. <\/p>\n
Christoph further compared the spread of Rust bindings to a cancerous tumor that would spread to all subsystems of the kernel, leading to fragmentation. From a unified whole, the kernel is turning into a project written in multiple languages, without a clear definition of when to use which language. According to Christoph, working with such a mixed codebase has become his worst nightmare, as it constantly requires rewriting code from one language to another and then back again. <\/p>\n
At the same time, Christoph is asking for clarification on the purpose of implementing Rust into the kernel. If the goal is to address security issues arising from low-level memory handling, then the existing code must be modernized first. Given that maintainers react painfully even to trivial matters, such as integer overflow checks, it is unclear how to bridge the gap between one part of the kernel that does not accept even basic security rules and another part that adheres strictly to them. If the aim is to simplify driver development, then introducing support for yet another language will only add to the workload and increase the burden on the already overloaded individuals keeping the kernel infrastructure operational. <\/p>\n
As for supporters of integrating Rust into the kernel, the following goals are mentioned: <\/p>\n
\n
Writing new code in Rust will reduce the risk of memory errors and race conditions, as well as eliminate some logical errors.\n
Maintainers will find it easier to review changes and refactor modules considering the guarantees provided by the Rust language.\n
Having abstractions that use advanced features of Rust will simplify the creation of new drivers and modules.\n
Support for a modern language will attract new participants to kernel development.\n
Utilizing the capabilities of the Rust toolchain will simplify the requirements for code documentation. For example, the Rust for Linux project has introduced a requirement for mandatory documentation of public APIs, security requirements, unsafe blocks, and type invariants. <\/ul>\n