Linus Torvalds has joined the discussion regarding the resistance of maintainers to the integration of Rust into the kernel, explaining that no one is forcing maintainers to learn the Rust language, use Rust code, or consider the presence of Rust code in the kernel. Maintainers can continue to work solely with C code and have no interaction with Rust. However, such maintainers cannot influence how Rust evolves in the kernel; for example, they cannot interfere with the organization of external interactions between Rust code and the code of their subsystem.
Maintainers interested in promoting Rust can get involved in development, thus providing them the opportunity to influence the construction of bindings in Rust and participate in the maintenance of interfaces in Rust. Maintainers who do not wish to deal with Rust can ignore the bindings in Rust, but they will also be unable to influence their development.
Thus, a kind of protective barrier is formed around developers who use only the C language, shielding them from the issues associated with Rust and allowing them to avoid interaction with Rust. However, this wall works both ways; therefore, if a developer does not want to deal with Rust, they also do not get the opportunity to influence the promotion of Rust. In other words, "no one is required to deal with Rust" does not mean that "every maintainer can veto any Rust code." It is assumed that the division among maintainers will not be so radical in practice, and some maintainers will begin to consider Rust bindings and collaborate with their developers, but without becoming too deeply involved in the process.
Med hensyn til situationen omkring bekræftelse af Rust-bindings over DMA-subsystemet forbi maintaineren, der forsøger at blokere for accept af sådanne bindings, kritiserede Linus Christoph Hellwig's handlinger. Ifølge Linus har Christoph overskredet sine beføjelser og forsøgt at påvirke kode, der ikke omhandlede DMA-subsystemet, var implementeret i en separat underkatalog og ikke påvirkede den kode, Christoph er ansvarlig for. Christoph har forsøgt at kontrollere, hvordan DMA-subsystemet anvendes, og hans handlinger kan sammenlignes med et forsøg på at forbyde brugen af DMA i en driver, blot fordi han ikke kunne lide den driver. Konklusion: selvom vedligeholdere er ansvarlige for deres kode, er de ikke ansvarlige for, hvordan og af hvem resultatet af det arbejde, de har udført, bruges.
Kilde: opennet.ru
