The introduction of Rust into the staunchly C enclave of Linux kernel development cannot avoid being controversial and indeed things have been heated. The anti-Rust revolt has been rumbling on for a few weeks now, but the top maintainers are dismantling the barricades.

There is nothing so deeply personal in the cold technie world of programming as the language you choose to work in. No matter how many languages you work with, there will be one you know so well that you think in it. For me, and I guess all of the  Linux maintainers, C is the language that forms our thoughts. Yet we all know that C is a language that all-too-easily allows mistakes to be made - hence we aspire to Rust, or some of us do.

I have to admit I was surprised when Linus allowed Rust code into the Kernel as he has long been a champion of C and has resisted using C++ in its place for many years. Now his stance is that Rust is ok, encouraged, and even seen as the future of Linux.

But the Linux community isn't swallowing the pill and getting on with coding.

Back in September 2024 a maintainer of the Rust for Linux project stepped down citing the negative attitude of the Linux C using community to his work. Things quieted down until a few weeks ago when Christoph Hellwig, a maintainer of the DMA system, complained about software in Rust that made use of his code:

"If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems."

Yes he likened to cancer, not Rust but the act of using more than on language on a project. The problem that is being raised is that you may decide that C is the language you want to use, but you are going to have to face the complications of understanding the interactions between Rust and C code. Hellwig refused to maintain the interaction layer between the two languages and refused an offer for someone else to take it over:

"Which doesn't help me a bit. Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language completely breaks this. You might not like my answer, but I will do everything I can do to stop this."

This in turn lead to another maintainer, Hector Martin, to point out that this removes any hope for the Rust for Linux (R4L) project:

"The reason this is sabotaging the entire R4L project is that DMA abstractions are critical for 99% of drivers, and without them, the R4L project is dead in its tracks. Christoph is fundamentally opposed to the goals and technical plan behind R4L, and offers no viable technical alternatives. If his demands are met, the R4L project is effectively dead with no way out, and that is what he wants. This is the dictionary definition of sabotage."

He then went on to ask for Linus to step in and save the day.  Linus did step in, but not with what you might have been expecting:

If shaming on social media does not work, then tell me what does, because I'm out of ideas.

How about you accept the fact that maybe the problem is you.

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.

Linus did then merge the disputed code, so siding with the Rust faction. However, the merged code was not under the supervision of the DMA maintainer. Linus writes:

"The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form.

I find it distressing that you are complaining about new users of your code, and then you keep bringing up these kinds of complete garbage arguments. Honestly, what you have been doing is basically saying "as a DMA maintainer I control what the DMA code is used for". And that is not how *any* of this works."

He then goes on to say that there is no pressure on maintainers to use Rust, but they cannot block the use of Rust by other maintainers:

"So this email is not about some "Rust policy". This email is about a much bigger issue: as a maintainer you are in charge of your code, sure - but you are not in charge of who uses the end result and how."

This all very diplomatic and reasonable but somehow I don't think that this is going to make the Rust opposition go away - it might, however, make the Rust opponents go away. Martin quit as a Linux maintainer and resigned from the Asahi Linux project.

At the same time, Greg Kroah-Hartman, usually considered to be second in command of the Linux project, has been promoting the Rust cause:

"As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic. The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust."

As I said in Rust And C++ Should Be Friends?

So it is with Rust and C++ programmers. The Rust programmers like to push the boundaries of the borrow checker and the C++ programmers like to chase bugs.

The move to a new language may be justified on good technical grounds, but which language you think in is deeply embedded and will take time to change.

Mike James is Chief Editor of I Programmer and the author of several programming books in the I Programmer Library, the latest of which is Deep C Dives: Adventures in C (I/O Press).

More Information

rust: add dma coherent allocator abstraction

On community influencing

Rust kernel policy

In praise of Rust

Related Articles

Rust And C++ Should Be Friends?

Rust Bringing Greater Safety To Linux

Linus On Linux 2024

The Feds Want Us To Move On From C/C++

DARPA Wants All C Converted To Rust

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

<ASIN:1871962889>