Efforts to add Rust code to the Linux kernel suffered a setback last Thursday when one of the maintainers of the Rust for Linux project stepped down - citing frustration with "nontechnical nonsense."

Wedson Almeida Filho, a software engineer at Microsoft who has overseen the Rust for Linux project, announced his resignation in a message to the Linux kernel development mailing list.

"I am retiring from the project," Filho declared. "After almost four years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them."

I expected we would be past tantrums from respected members of the Linux kernel community

Filho thanked the Rust to Linux team and reiterated his support for the project - which aims to bring the memory safety advantages of the Rust language to the C-based Linux kernel.

Memory safety bugs are regularly cited as the major source of serious software vulnerabilities by organizations overseeing large projects written in C and C++. So in recent years there's been a concerted push from large developers like Microsoft and Google, and well as from government entities like the US Cybersecurity and Infrastructure Security Agency, to use memory-safe programming languages - among them Rust.

Discussions about adding Rust to Linux date back to 2020 and were realized in late 2022 with the release of Linux 6.1.

"I truly believe the future of kernels is with memory-safe languages," Filho's note continued. "I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix."

And he concluded his message with a reference to
a YouTube video from the Linux Storage, Filesystem, Memory-Management, and BPF Summit in May. Pointing to a portion of the video as an example of the kind of interaction that led him to step down, Filho wrote, "[T]o reiterate, no one is trying [to] force anyone else to learn Rust nor prevent refactorings of C code."

That remark is a response to a comment on the video that, according to Filho, came from Linux kernel maintainer Ted Ts'o: "Here's the thing, you're not going to force all of us to learn Rust."

The video depicts resistance to Filho's request to get information to statically encode file system interface semantics in Rust bindings, as a way to reduce errors. Ts'o's objection is that C code will continue to evolve, and those changes may break the Rust bindings - and he doesn't want the responsibility of fixing them if that happens.

The Register asked Ts'o to comment but we've not received a response at the time of writing.

Interpersonal conflict is common in open source projects - particularly among those working on a volunteer basis, who may come from different backgrounds and may have different expectations about the deliberative process. Absent the restraint of corporate workplace rules, open source projects live and die on their state community norms, and by the social finesse of people charged with governing those norms.

But the rules put in place to guide open source communities tend not to constrain behavior as comprehensively as legal requirements. The result is often dissatisfaction when codes of conduct or other project policies deliver less definitive or explainable results than corporate HR intervention or adversarial litigation.

In an email to The Register, Filho elaborated on his rationale for resigning from the Rust for Linux project, describing his frustration with what's often referred to as "bikeshedding" - arguments over insubstantial matters that derail a more consequential goal.

"When I started on this project, I fully expected we would get pushback on technical grounds and I was willing to work through that under the assumption that eventually we would find consensus," explained Filho.

"Almost four years into this, I expected we would be past tantrums from respected members of the Linux kernel community. I just ran out of steam to deal with them, as I said in my email."

"If it isn't obvious, the gentleman yelling in the mic that I won't force them to learn Rust is Ted Ts'o. But there are others. This is just one example that is recorded and readily available."

Citing the Linux kernel community's reputation for undiplomatic behavior, The Reg asked whether kernel maintainers need to learn how to play well with others.

Filho replied: "Well, I suppose it depends on what their goals are."

As to the sentiment expressed about the disinterest among kernel maintainers in learning Rust, Filho said there's no expectation of that.

"I've heard in the past from several maintainers that they're just overburdened and don't have time for anything else," he noted. "I'm sympathetic to their plight. Those who can't or don't want to be involved are obviously welcome to stay away. This does not (and did not) bother me at all."

Nonetheless, Filho believes the effort to add Rust code to the kernel is mostly going well.

"The team has been setting the groundwork for new components/drivers to be written in Rust but as these are developed, we're running into some roadblocks," he told us. "[Linux creator Linus] Torvalds doesn't seem to care, or perhaps believes they are appropriate. Time will tell."

In a post to Mastodon, developer Asahi Lina expressed sympathy for Filho's decision: "A subset of C kernel developers just seem determined to make the lives of the Rust maintainers as difficult as possible. They don't see Rust as having value and would rather it just goes away."

Veteran developer Drew DeVault, founder and CEO of SourceHut and a critic of Rust in the Linux kernel, expressed sympathy for those working on the Rust for Linux project while also proposing a change of direction.

In a blog post on Friday, DeVault likened dealing with the Linux community to herding cats. "The consequences of these factors is that Rust for Linux has become a burnout machine," he wrote.

As an alternative, he has proposed starting anew, without trying to wedge Rust into legacy C code. He wrote that "a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML [Linux kernel mailing list] politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production-ready for some use cases within a few years." ®

https://www.theregister.com//2024/09/02/rust_for_linux_maintainer_steps_down/