3 ms·

I’ve read many times that a goal is to see if the use of Rust can work out in the kernel. What does this experiment for? What exactly is the evaluation? What a

I’ve read many times that a goal is to see if the use of Rust can work out in the kernel. What does this experiment for? What exactly is the evaluation? What are some example findings, both pro and con?

steveklabnik 2y ago
You can find the home of the project here: https://rust-for-linux.com/ https://rust-for-linux.com/ Linus has been talking publicly over the last few years about how it’s getting harder and harder to find maintainers. There are various reasons for this, but C is part of the problem. If there are newer technologies that would be appropriate for the kernel, they should be investigated. At the same time, more and more downstream users of the kernel have been adopting Rust, and more kernel devs have been checking out Rust and have liked what they’ve seen. Many also don’t, to be clear, but the point is that a group of people were willing to put in the work to give Rust a real shot, and so did some initial work to sketch it out. Linus agreed to give it a try, but there are some caveats: Rust code cannot hold up improvements to the C code. Changes to the C are allowed to break the Rust, in other words. Then, it was discussed that the right first place to try Rust would be in driver code. This has the advantage of being a real project, but also sidesteps another issue: today, Rust doesn’t support every platform Linux does. Drivers are platform specific, so you just simply only write drivers for platforms Rust supports. So far, there have been some successes: some example drivers have been written. There’s also been some struggles: there are some experimental features of Rust and its standard library that the code relies on. But the Rust project has committed to trying to get those finished sometime soon, so that’s not a permanent issue. There have also been some… skepticism of both Rust and the experiment by some members of the kernel development community, and that’s caused some problems. Hopefully those can be worked out too.
- Waterluvian 2y ago
  Thanks for the thorough details. That really helped my mental model of the topic. > ...some experimental features of Rust and its standard library that the code relies on. In my work I've experienced this, which can cause a sort of inversion where usage of experimental (or non-documented) features become so relied upon that I lose most control over how the experiment might resolve (ie. sorry, now it must find its way into main). Any concerns of the same kind of thing?
  - steveklabnik 2y ago
    You're welcome. > Any concerns of the same kind of thing? Here's the canonical list: https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2 There's a lot, and I don't know the status of many of them, personally. But I don't see anything there that I know is not gonna work out, like for example, they aren't using specialization. Most of it feels like very nuts and bolts codegen options and similar things. That said, back in August, the Rust Project announced their goals for the second half of this year: https://blog.rust-lang.org/2024/08/12/Project-goals.html https://blog.rust-lang.org/2024/08/12/Project-goals.html They say that they're committed to getting this stuff done, and in particular: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html#the-next-six-months https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st... > Closing these issues gets us within striking distance of being able to build the RFL codebase on stable Rust. So, things sound good, in my mind.

steveklabnik 2y ago

You can find the home of the project here: https://rust-for-linux.com/ https://rust-for-linux.com/ Linus has been talking publicly over the last few years about how it’s getting harder and harder to find maintainers. There are various reasons for this, but C is part of the problem. If there are newer technologies that would be appropriate for the kernel, they should be investigated. At the same time, more and more downstream users of the kernel have been adopting Rust, and more kernel devs have been checking out Rust and have liked what they’ve seen. Many also don’t, to be clear, but the point is that a group of people were willing to put in the work to give Rust a real shot, and so did some initial work to sketch it out. Linus agreed to give it a try, but there are some caveats: Rust code cannot hold up improvements to the C code. Changes to the C are allowed to break the Rust, in other words. Then, it was discussed that the right first place to try Rust would be in driver code. This has the advantage of being a real project, but also sidesteps another issue: today, Rust doesn’t support every platform Linux does. Drivers are platform specific, so you just simply only write drivers for platforms Rust supports. So far, there have been some successes: some example drivers have been written. There’s also been some struggles: there are some experimental features of Rust and its standard library that the code relies on. But the Rust project has committed to trying to get those finished sometime soon, so that’s not a permanent issue. There have also been some… skepticism of both Rust and the experiment by some members of the kernel development community, and that’s caused some problems. Hopefully those can be worked out too.

Waterluvian 2y ago
Thanks for the thorough details. That really helped my mental model of the topic. > ...some experimental features of Rust and its standard library that the code relies on. In my work I've experienced this, which can cause a sort of inversion where usage of experimental (or non-documented) features become so relied upon that I lose most control over how the experiment might resolve (ie. sorry, now it must find its way into main). Any concerns of the same kind of thing?
- steveklabnik 2y ago
  You're welcome. > Any concerns of the same kind of thing? Here's the canonical list: https://github.com/Rust-for-Linux/linux/issues/2 https://github.com/Rust-for-Linux/linux/issues/2 There's a lot, and I don't know the status of many of them, personally. But I don't see anything there that I know is not gonna work out, like for example, they aren't using specialization. Most of it feels like very nuts and bolts codegen options and similar things. That said, back in August, the Rust Project announced their goals for the second half of this year: https://blog.rust-lang.org/2024/08/12/Project-goals.html https://blog.rust-lang.org/2024/08/12/Project-goals.html They say that they're committed to getting this stuff done, and in particular: https://rust-lang.github.io/rust-project-goals/2024h2/rfl_stable.html#the-next-six-months https://rust-lang.github.io/rust-project-goals/2024h2/rfl_st... > Closing these issues gets us within striking distance of being able to build the RFL codebase on stable Rust. So, things sound good, in my mind.