Ghostboard pixel

After Recent Kernel Drama, Rust for Linux Policy Put in Place

The recent Linux kernel drama over Rust code has resulted in the creation of a Rust kernel policy.

A new Linux kernel drama has unfolded over these past few weeks, where the maintainer of the DMA mapping helper code refused to accept Rust code. This gave rise to a flurry of arguments from many kernel contributors and even on social media, resulting in one of the contributors eventually quitting over loss of faith in the kernel development process.

I won't go too much into the details of the tiff, but words like β€œcancer” were thrown around when referring to the maintenance overhead of having a cross-language codebase in the Linux kernel. You can go through the whole thread if you are up for a long read.

Interestingly, a major development has now taken place with a Rust kernel policy being put in place to prevent future conflicts.

Rust Kernel Policy: What to Expect?

the photo consists of a lot of text with the main title reading rust kernel policy

Posted by Miguel Ojeda, lead of the Rust for Linux project, this new policy looks to help set the record straight surrounding Rust integration in Linux. If you were not familiar, Rust for Linux is an initiative that's been working towards bringing the advantages of the Rust programming language into the Linux kernel.

It is backed by a community of developers who come from different backgrounds and organizations, with a couple of notable sponsors acting as a driving force.

In its current state, the Rust kernel policy reflects the Rust for Linux team’s best understanding of Rust kernel development, while remaining open to changes.

It lays out key topics like how Rust for Linux is not an effort by the Rust Project or the Rust Foundation, how many key kernel maintainers do support Rust in the kernel, and how changes are not allowed to be introduced if a C change breaks a Rust-enabled build (with an exception for Rust subsystems).

Regarding whether duplicate C or Rust-based drivers are allowed, the policy states that, by default, they are not allowed. However, subsystems may temporarily allow them to make it easier to introduce Rust support and get it working smoothly.

All of that does clarify a lot, and one can only hope that, going forward, this policy will gradually reduce the friction between Rust for Kernel contributors and Linux kernel maintainers.

You can take a look at the Rust kernel policy if you would like to know more.

Suggested Read πŸ“–

No Russians in my Kernel! Geopolitics Reaches Linux Project
So, geopolitics into the mix, and it is a US-thing, or not?
πŸŽ—οΈ
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.

Great! You’ve successfully signed up.

Welcome back! You've successfully signed in.

You've successfully subscribed to It's FOSS News.

Success! Check your email for magic link to sign-in.

Success! Your billing info has been updated.

Your billing was not updated.