Linus Torvalds has raised concerns about Rust’s automated formatting tool and pull request text formatting practices in a recent Linux Kernel Mailing List discussion.

The conversation started on October 2nd when he responded to the Direct Rendering Manager (DRM) subsystem’s pull request for Linux 6.18, submitted by maintainer Dave Airlie on October 1st. The pull request included Rust code additions for DRM drivers.

Linus first addressed what he saw as corrupted formatting in the pull request’s changelog. The hierarchical indentation showing the organization of different subsections had been flattened. Linus wrote:

Notice how there are multiple sub-areas: Alloc, DMA/Scatterlist, DRM and Rust. But it’s all just a random jumble, because you have apparently pasted it into your editor or MUA or whatever and dropped the indentation in the process.

Or something.

What kind of broken editor are you using? I’m not trying to start an emacs or vi war here, but you seem to be using something truly broken.

EDLIN?

He questioned what editor Dave was using, sarcastically suggesting EDLIN, a primitive line editor from the early MS-DOS era.

The Rust Problem

The more technical issue involved Rust’s formatting tool, rustfmt. While resolving a merge conflict, Linus reformatted multiple import statements to have each on its own line. This format makes it straightforward to add new imports later, which helps avoid merge conflicts.

However, when he ran the formatting checker, the tool flagged this and suggested compressing multiple imports onto a single line instead. Linus described this as “bass-ackwards garbage.” He expressed frustration with automated tooling making decisions that could complicate future merge conflicts.

The issue stems from Rust’s formatting rules that automatically decide when to use single-line versus multi-line formatting based on length. He ultimately ignored the formatting checker’s suggestions and asked Rust-for-Linux maintainer Miguel Ojeda if there was a “sane solution.”

Miguel responded with a measured explanation. He noted that rustfmt has configuration options for controlling import formatting, but they’re currently unstable and only available in nightly builds.

He clarified a miscommunication about the workflow and that his intention was for Linus to run the auto-formatter after resolving conflicts, not the checker designed for automated testing systems.

“Leaving non-formatted files does hurt us, though... e.g. CIs check it, and I think people are generally happy about the simplicity of formatting on the Rust side,” Miguel explained. He offered to discuss the issue with upstream Rust developers and find a compromise formatting style.

Regarding text formatting, Dave Airlie explained he intentionally flattens indentation. He receives 15-20 pull requests with varying formats and streamlines them for consistency.

Linus responded by comparing workloads. Between kernel versions 6.16 and 6.17, Dave merged 48 pull requests, while he handled 441 merges, nearly ten times more. “I do closer to AN ORDER OF MAGNITUDE more merges than you do. And I spend the time and try to do it right,” Linus wrote.

In the end, both sides appear willing to find solutions. As of October 6th, 2025, the conversation seems to have wound down with no further responses from Dave Airlie.

Suggested Read📖

New Proposal Looks to Make Linux Multi-Kernel FriendlyIf approved, Linux could one day run multiple kernels simultaneously.Sourav Rudra 🎗️

Here’s why you should opt for It’s FOSS Plus Membership:

• Even the biggest players in the Linux world don’t care about desktop Linux users. We do.
• We don’t put informational content behind paywall. Your support keeps it open for everyone. Think of it like ‘pay it forward’.
• Don’t like ads? With the Plus membership, you get an ad-free reading experience.
• When millions of AI-generated content is being published daily, you read and learn from real human Linux users.
• It costs just $2 a month, less than the cost of your favorite burger.

Become a Plus Member today and join over 300 people in supporting our work.