Linus Torvalds joined the discussion about the resistance of maintainers to the implementation of Rust in the kernel, explaining that no one is forcing maintainers to learn Rust, use Rust code, or consider the presence of Rust code in the kernel. Maintainers can continue working solely with C code and have no need to interact with Rust. However, such maintainers cannot influence how Rust develops in the kernel; for example, they cannot interfere with the organization of external interactions between Rust code and the code of their subsystem.
Maintainers who are interested in promoting Rust can be involved in its development and thus gain the ability to influence the construction of Rust bindings and participate in the maintenance of Rust interfaces. Maintainers who do not wish to deal with Rust can remain unconcerned about Rust bindings, but they will not be able to influence their development.
Thus, a sort of protective wall surrounds developers who use only C, shielding them from issues related to Rust and allowing them to avoid Rust altogether. But this wall works both ways; if a developer does not want to deal with Rust, they do not gain the ability to influence Rust's advancement. In other words, "no one is required to deal with Rust" does not imply that "every maintainer can veto any Rust code." It is anticipated that in practice, the division among maintainers will not be so radical, and some maintainers will start to consider Rust bindings and collaborate with their developers, albeit without deeply immersing themselves in the process.
Regarding the situation with the confirmation of Rust bindings over the DMA subsystem, bypassing the maintainer who is trying to block the acceptance of such bindings, Linus criticized Christoph Hellwig's actions. According to Linus, Christoph overstepped his authority and attempted to influence code that did not affect the DMA subsystem, was implemented in a separate subdirectory, and did not impact the code for which Christoph is responsible. Christoph tried to control how the DMA subsystem is used, and his actions can be compared to attempting to ban the use of DMA in a certain driver just because he disliked that driver. The conclusion: although maintainers are responsible for their code, they are not accountable for how and by whom the results of that code are used.
Source: opennet.ru
