Christoph Hellwig, the maintainer of the DMA subsystem, KVM, Slab Allocator, and PowerPC architecture in the Linux kernel, who was once a member of the technical steering committee of the Linux Foundation and was a plaintiff in a GPL-related lawsuit against VMware, refused to accept patches related to support for driver development in Rust. The proposed patches added wrappers over several functions of the DMA subsystem, allowing DMA to be used in drivers written in Rust.
The stated reason for the refusal was the increased complexity of code maintenance with wrappers in other languages and the desire to keep the software interfaces to DMA in a readable C language format, without muddling it with obscure wrappers. Christoph suggested directly accessing the original C API for DMA in each driver written in Rust to avoid creating additional abstractions that kernel maintainers would have to depend on.
The patch developers indicated that they would take on all the work of maintaining the Rust code, were ready to manage these patches themselves, and moved the wrappers to a separate subdirectory (rust/kernel/dma.rs). In response, Christoph issued a veto ('Nacked-by') against accepting the related Rust patches and stated that he did not want another maintainer. Christoph declared that if the wrapper developers wanted to create an unmaintainable Linux due to mixing several languages in one codebase, they should do it in their driver instead of spreading this cancerous growth to core kernel subsystems.
At the same time, Christoph clarified that he has nothing against the Rust language and considers it one of the best new languages, but he is against mixing code in different languages. According to Christoph, he supports the creation of new projects in Rust but is against mixing Rust with large codebases in C, as such mixing significantly reduces the maintainability of the kernel as an integrated project.
The essence of the problems with maintenance is that Rust bindings make maintainers dependent on code written in Rust. At first glance, it seems that these bindings are merely extensions to C structures and functions, which does not impact the development and maintenance of C code. However, that is not the case. With such bindings in place, developers of subsystems written in C must consider the impact of their changes on the continued functionality of the bindings. Any change in data structures or internal functions in C may necessitate changes in the bindings’ code, so changes affecting the bindings in C code need to be monitored and synchronized with the Rust code. Many maintainers are unwilling to take on the additional responsibility for fixing issues arising in Rust code and do not intend to spend their time tracking the status of Rust bindings.
The situation with the complexity of maintenance is not theoretical. Jason Gunthorpe, a maintainer of TPM, VFIO, and Infiniband at NVIDIA, joined the discussion and cited an example where Linus Torvalds rejected a pull request with changes in the memory management subsystem because it caused a crash when attempting to build the kernel with Rust support enabled. The crash occurred because the Rust code maintainers had not added the necessary changes to the bindings generator (bindgen). Thus, the maintainers of the memory management subsystem, while pushing a change that was fully correct from the perspective of C code and the kernel as a whole, found themselves dependent on optional third-party code in the kernel, for which other people are responsible.
The refusal to accept wrapping code over DMA calls put the developers of the Rust for Linux project in a bind, as without such bindings, developing full-fledged drivers in Rust would be challenging. Hector Martin, maintainer of the code supporting Apple ARM chips and leader of the Ashai Linux project, suggested as a way to resolve the conflict to seek acceptance of the binding directly through Linus Torvalds, bypassing the maintainer of the DMA subsystem. If Linus agrees to such a breach of subordination and established practices, it could lead to a crisis in kernel development management; if he refuses, it would halt the advancement of Rust in the kernel.
As an option, Hector mentioned holding Christoph accountable for violating the code of conduct due to a comment where Christoph compared Rust to a cancerous tumor. Furthermore, Hector expressed his frustration with all the bureaucratic red tape, stating that he was not ready to simply trust established processes and hinted at involving social media. Dave Airlie, the maintainer of the DRM subsystem, advised against escalating the conflict and emphasized that toxic behavior is unacceptable from both sides, regardless of who is right or wrong in the discussion.
Linus Torvalds joined the discussion, pointing out that the problem may lie with Hector himself and his overconfidence in knowing something better than others, rather than with the current kernel development process which is functioning. The kernel development process has its issues, but that's a reality of life — nothing is perfect. Attempts at social media harassment discourage Linus from wanting to have anything to do with Hector's approach. Technical discussions and patches matter to Linus, not pressure through social media.
In response, Hector submitted a request to remove himself from the ARM/APPLE platform maintainers as he lost faith in the kernel development process and community management approach being applied. He also stated that development for the ARM/Apple platform would continue outside the main Linux kernel. There remains one more maintainer for the ARM/Apple platform in the kernel — Sven Peter, who intends to continue supporting the platform in the kernel.
Source: opennet.ru
