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. <\/p>\n
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. <\/p>\n
Patch developers have stated that they will take on all the work to maintain the Rust code, are prepared to support these patches themselves, and have moved the wrappers to a separate subdirectory (rust\/kernel\/dma.rs). In response, Christoph vetoed (\u2018Nacked-by\u2019) the acceptance of the related Rust patches and indicated that he does not need another maintainer. Christoph asserted that if the wrapper developers wish to create an environment where Linux maintenance becomes impossible due to the mixing of several languages in one codebase, they should do so in their own driver rather than spreading this cancerous growth to the core subsystems. <\/p>\n
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. <\/p>\n
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\u2019 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. <\/p>\n
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. <\/p>\n
The refusal to accept the wrapping code around DMA calls has put the developers of the Rust for Linux project in a bind, as without such wrappers, developing full-fledged drivers in Rust will 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 that they seek acceptance of the wrapper directly through Linus Torvalds, bypassing the maintainer of the DMA subsystem. If Linus agrees to such a breach of hierarchy and established practice, it could lead to a management crisis in kernel development; if he refuses, it will halt the advancement of Rust in the kernel. <\/p>\n
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. <\/p>\n
Linus Torvalds joined the discussion, pointing out that the problem may lie with Hector himself and his arrogance in thinking he knows better than others, rather than with the current kernel development process, which is functional. The kernel development process has issues, but this is the reality of life\u2014nothing is perfect. Attempts to bully through social media are what discourage Linus from wanting anything to do with Hector's approach. Technical discussions and patches matter to Linus, not pressure tactics through social media. <\/p>\n