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.
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.
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 π
Stay updated with relevant Linux news, discover new open source apps, follow distro releases and read opinions