Dev

‘Maybe the problem is you’ … Linus Torvalds wades into Linux kernel Rust driver drama


Weighing in on yet another Linux kernel spat – this time over Rust device drivers – Linux supremo Linus Torvalds has shot the messenger.

In response to Asahi Linux lead developer Hector Martin’s call for Torvalds to “pipe up with an authoritative answer” to resolve the device driver impasse, and Martin’s defense of “shaming on social media” as a way to counter the hostility of Linux maintainers to Rust code, Torvalds dismissed the approach and took aim at Martin.

“How about you accept the fact that maybe the problem is you,” said Torvalds, who several years ago acknowledged his own difficulty with diplomatic online interaction. “You think you know better. But the current process works.

“It has problems, but problems are a fact of life. There is no perfect.

“However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.

“Because if we have issues in the kernel development model, then social media sure as hell isn’t the solution. The same way it sure as hell wasn’t the solution to politics.

“Technical patches and discussions matter. Social media brigading – no thank you.”

Torvalds’ relatively restrained message – not all that different from Apple’s discontinued omertà advisory to developers, “If you run to the press and trash us, it never helps” – landed hard. Shortly thereafter, Martin asked to be removed as a maintainer of the upstream Linux code that provides support for Apple’s Arm-compatible hardware.

Martin was accused of “brigading” – rallying support on social media – after clashing with kernel maintainer Christoph Hellwig. The dispute stemmed from Hellwig’s opposition to a patch proposed last month that would allow Rust-written device drivers to call the mostly C-based kernel’s core DMA API, which allocates and maps memory regions for direct memory access.

The Linux kernel has been written mainly in C code, which alongside C++ has become unfashionable in recent years because programming languages with manual memory management allow developers to make memory safety errors. In some cases, these can have serious security consequences.

Rust, a newer programming language, is designed to enforce memory safety through its ownership model, preventing many common vulnerabilities found in C and C++. As a result, it has been widely promoted as a way to reduce memory safety issues in software development.

The Linux kernel began integrating Rust code in 2022, but it remains largely a C-focused code base. Many C programmers who contribute and maintain the code have made it clear they’re not going to change their ways because Rust is on the rise.

The tension between C and Rust developers in the Linux kernel stems from Rust’s memory safety features being introduced into a traditionally C-dominated codebase, with some maintainers resisting the added complexity and potential maintenance burden.

As we reported previously, Hellwig’s emphatic rejection of the patch led Martin to urge the Rust for Linux team to “just merge this series once it is reviewed and ready, ignoring Christoph’s overt attempt at sabotaging the project.”

On Tuesday, Martin posted a message advising against engaging in drama – despite an impassioned, now-removed Mastodon post on the matter – because Torvalds has the final say about whether the device driver patch is accepted.

“Either Linus likes it, or he doesn’t,” he wrote. “Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they’re going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages.”

But Rust aversion among kernel maintainers may slow that movement down for the Linux community. The fate of the patch has yet to be determined. ®



READ SOURCE

This website uses cookies. By continuing to use this site, you accept our use of cookies.