A policy for inclusion of Rust in the Linux Kernel | Hacker News Reader

A policy for inclusion of Rust in the Linux Kernel

news.itsfoss.com

2 pointsfork-bomber13 comments

Plan for a Rust-Based Fork of the Linux Kernel

Background & Motivation

Linux is a monolithic kernel, making it difficult to incrementally introduce Rust without significant modifications. While Rust is being integrated into the kernel for drivers, deeper adoption requires a more fundamental shift. A full Rust-based fork would allow leveraging Rust’s safety features across core kernel components.

Key Goals 1. Process Management in Rust – Rewrite the scheduler and process handling to improve memory safety. 2. Synchronization Primitives – Implement mutexes, spinlocks, and RCU using Rust for safer concurrency. 3. Filesystem & VFS Layer – Enhance security and stability with Rust-based abstractions. 4. Kernel Drivers in Rust – Replace legacy C-based drivers with Rust implementations where feasible.

Challenges • Rewriting large portions of Linux is costly and time-consuming. • Ensuring compatibility between Rust and existing C subsystems. • Gaining support from the Linux development community.

Approach

Instead of a complete rewrite, a modular approach can incrementally introduce Rust subsystems, ensuring compatibility while leveraging Rust’s benefits. Although existing Rust-based kernels like Redox OS are not yet competitive, a forked Rust-Linux could lay the foundation for a safer and more maintainable kernel.

Wouldn't it be better to build a Rust only operating system? Is anyone doing that? If Torvalds can do it, why not?

Reaching parity with Linux's immense suite of device drivers is perhaps the single biggest hurdle.

That's one of the biggest reasons why alternative kernels either remain fringe or fail.

Initiatives such as NetBSD's Rump kernel but for Linux may provide a bridge to Linux's drivers but it's brittle. There's already LKL - the Linux Kernel Library project with similar aims but not much traction.

There are a few projects for Rust only OSes. Redox aims at the desktop, Hubris aims at microcontrollers, to name two I'm aware of.

But there's a huge difference between "let's make it easier for driver writers to write correct drivers by using Rust in the OS we all already use" and "let's create a whole OS and convince driver writers to write drivers for it and then users to use it".

> If Torvalds can do it, why not?

I genuinely doubt Torvalds (even a young version of him) could build a new competing OS in modern times, and have it succeed.

Linux succeeded in a much, much simpler world. What needs to succeed now is something that compares not to the initial Linux, but to the Linux 30 years later, with mountains of effort piled up on top. That is no longer something that can be achieved by any single person, no matter how motivated.

Linux kernel devs want to work on Linux, not on other OSes.

Companies depend on Linux and want to improve their products, not rebuild a massive codebase from scratch.

There will be a backlash resulting in a Rust-free Linux fork.

That's quite unlikely. What's more likely is the emergence of a better approach for incremental inclusion of Rust in the kernel. This policy is a decent stake in the ground.

Incremental is not going to work for someone who doesn't want to install any Rust stuff to compile their kernel or understand Rust to work in the kernel.

Possibly. What's more likely is that folks would want to ask why major corporations are willing to invest the dollars to commit to Rust and it's take on memory safety, at scale.

Once that's internalised, those 'someone's may either align or be the outliers that don't matter in the greater scheme.

Linux kernel work is being done by countless embedded outfits all around the globe. Rust is completely misaligned with the embedded skill set and attitude; there will be a clash and backlash. Embedded people don't want to be told, you can't shove that value obtained here into there because of some cockamamie language rule.

I assume you allude to Rust's borrow checker. If you are, your concern is misplaced: which is a common occurrence unfortunately when it comes to this topic. Note that most of the interaction with the borrow checker's rules would be tackled by the interfaces between Rust and C that are being incrementally added to the kernel. By the time the 'end users' (the embedded Linux device driver authors you allude to) are involved, all they are doing is using safe Rust wrappers for loads and stores to MMIO, as an example, where there is no fundamental interaction with the borrow checker (because those happen at another level in the call graph involved).

That said: To appreciate the value Rust provides there is going to be some experience driven knowledge gain needed but the efforts underway should help.

Assuming the experiment is a success, that’s quite possible, but I would expect it to go similarly to the Rust-free Firefox forks: harder and harder to keep up over time as upstream diverges more and more. Plus, they’ll have to re-write a bunch of Rust drivers.

We’ll see what happens!

Reply on news.ycombinator.com