Developers trying to add Rust code to the Linux kernel continue to face opposition from kernel maintainers who believe using multiple languages is an unwelcome and risky complication.

Concerns surfaced last September when Microsoft software engineer Wedson Almeida Filho stepped away from the Rust for Linux project, citing frustration with “nontechnical nonsense” – which is one way to describe the difficulty of collaborating with those who have different goals.

Don’t force me to deal with your shiny language of the day. Maintaining multi-language projects is a pain

The issue flared again last month, when a proposed abstraction to allow Rust-written device drivers to call the primarily C-based kernel’s core DMA API met resistance from kernel maintainer Christoph Hellwig.

Specifically, a patch was submitted that would allow Rust drivers to use the DMA API’s dma_alloc_coherent() C function to allocate and map large memory regions for direct memory access by hardware.

In a message to the Linux kernel mailing list, Hellwig wrote: “No Rust code in kernel/dma, please.” For what it’s worth, the patch added code to the rust/kernel portion of the Linux source tree, not kernel/dma, as far as we can tell.

Miguel Ojeda of the Rust for Linux project asked Hellwig to suggest an alternative.

Hellwig replied: “Keep the wrappers in your code instead of making life painful for others,” and went on to argue that “interfaces to the DMA API should stay in readable C code and not in weird bindings so that it [remains] greppable and maintainable.” Hellwig’s wish seems to be that non-C drivers have their own private bindings to C code, and that these abstractions are not maintained separately, not even in the rust/kernel tree.

Challenged by Danilo Krummrich, a Red Hat software engineer involved in the Rust for Linux project, Hellwig makes clear that he’s just not keen to deal with Rust code.

“Don’t force me to deal with your shiny language of the day,” he wrote. “Maintaining multi-language projects is a pain I have no interest in dealing with. If you want to use something that’s not C, be that assembly or Rust, you write to C interfaces and deal with the impedance mismatch yourself as far as I’m concerned.”

In response, Krummrich explained the Rust for Linux effort is creating Rust code that abstracts the C APIs for all Rust drivers and is maintained by Rust devs. In other words, the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings.

But Hellwig doesn’t appear to be interested in having DMA Rust abstractions maintained separately. He explained that he does not want another maintainer:

Students of tech history may recall that Linux itself was likened to cancer by former Microsoft CEO Steve Ballmer in 2001. “Linux is a cancer that attaches itself in an intellectual property sense to everything it touches,” Ballmer said, back before Linux had metastasized into the Windows Subsystem for Linux.

Hellwig went on to argue that having others maintain the Rust abstraction layer for the DMA coherent allocator as a separate component doesn’t improve matters and hinders kernel maintainability:

Hector Martin, project lead of Ashai Linux, shared his belief that Hellwig’s remarks constitute a Code of Conduct violation but doubts any disciplinary action would be taken. The Register asked Martin whether he intends to file a Code of Conduct complaint, and we’ve not heard back.

Martin argues that the Rust for Linux developers should ignore Hellwig’s concerns and submit their patch for approval by kernel boss Linus Torvalds:

“If Linus doesn’t pipe up with an authoritative answer to this thread, Miguel and the other Rust folks should just merge this series once it is reviewed and ready, ignoring Christoph’s overt attempt at sabotaging the project. If Linus [accepts the pull request], what Christoph says doesn’t matter. If Linus doesn’t [accept it], the [Rust for Linux] project is essentially dead until either Linus or Christoph make a move. Everything else is beating around the bush.”

The Register asked Hellwig whether he wished to comment for this article and he declined. We also sought comment from Linux Foundation Fellow Greg Kroah-Hartman, who has not responded.

The case for Rust

The Linux kernel added support for Rust code on October 3, 2022, shortly after Microsoft Azure CTO Mark Russinovich argued that new programming projects should be written in Rust rather than C or C++.

“For the sake of security and reliability, the industry should declare those languages as deprecated,” Russinovich said.

His rationale is that Rust code can be written to avoid the memory safety bugs (eg, buffer overflows) that plague C and C++ code and represent the majority of serious vulnerabilities in large projects. That view has since attracted the support of government security organizations around the world.

There are people who just don’t like the notion of Rust, and having Rust encroach on their area

Those who write C and C++ code have taken note of the growing interest in Rust and acknowledged that memory safety concerns need to be addressed. Hence there are numerous projects underway, like TrapC, FilC, Mini-C, and Safe C++ that aim to make C and C++ less vulnerable to memory bugs, in addition to efforts like DARPA’s TRACTOR to automatically convert C code to Rust.

Shortly after Filho announced his departure from Rust for Linux last year, Linux honcho Linus Torvalds addressed the friction between C and Rust developers at the Linux Foundation’s Open Source Summit in Vienna, Austria.

“Clearly, there are people who just don’t like the notion of Rust, and having Rust encroach on their area,” Torvalds said. “People have even been talking about the Rust integration being a failure … We’ve been doing this for a couple of years now so it’s way too early to even say that, but I also think that even if it were to become a failure – and I don’t think it will – that’s how you learn.”

So far, the Linux developer community has learned that Rust isn’t always welcome. ®