11 ms·

I like Rust. I use it daily, at work and for personal projects. I can definitely see many advantages in Rust that would add value to the Linux kernel. However,

I like Rust. I use it daily, at work and for personal projects. I can definitely see many advantages in Rust that would add value to the Linux kernel. However, I feel like there are two definite things currently missing in the language that need to be implemented ASAP for the rust + linux kernel story to truly work. Panics (Rust's term for exiting a program when encountering an unhandled error) are a good idea in most environments - instead of reading or writing past a vector's last element, the program immediately exits. This approach falls through when you're in an incredibly high stakes environment that must absolutely avoid crashes. Sure, you can catch some panics [0], but you can not easily avoid them entirely. There is no surefire way to know if subroutines any level deep may panic. Linus himself mentioned this problem, so I think handling it should be a top priority. What's also definitely missing is an allocator strategy. Zig is a good example for this, you can choose the exact allocation method that fits your model. [0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html#notes https://doc.rust-lang.org/std/panic/fn.catch_unwind.html#not...

pornel 4y ago
Linux has kernel panics, and they predate Rust. You can't just dereference NULLs or spray random memory and still "absolutely avoid crashes". If you let C code write past end of a vector, you will have an unstable system and data corruption. Catching these bugs before they cause damage is an improvement to stability. In Rust you can compartmentalize panics. Instead of messing up the whole kernel or causing a machine-halting kernel panic, you can gracefully unwind one call and execute a fallback or return an error code from the one syscall that hit the bug. That is how you can continue running the kernel reliably instead of hoping to get lucky. Then, there was a miscommunication between the Linux Rust project and Linus, about an issue that does not exist any more. An early draft had a handler that translated OOM to kernel panics as a kludge from use of Rust's standard library containers as a placeholder for proper containers being developed. Linus rightly criticized that this was a bad idea, but it was never meant to be the final setup. That code has been replaced now, and Rust in the kernel uses fallible allocation that does not abort nor panic. The issue does not exist in the no-alloc Rust dialect used in the kernel going forward.
- selfmodruntime 4y ago
  You are entirely correct.
brabel 4y ago
Wouldn't it be possible to make gcc (optionally?) add https://docs.rs/no-panic/latest/no_panic/ https://docs.rs/no-panic/latest/no_panic/ to every function it compiles? Sure, that may make most Rust code not compile, but for kernel devs, this may not be too much of a hindrance as they may only use a small subset of crates which could be all made compile with this option.
- selfmodruntime 4y ago
  If you read the caveats section of the crate, you will find that it is quite limited in its capabilities. I firmly believe that panic-free guarantees need to be built into the compiler with a special flag.

pornel 4y ago

Linux has kernel panics, and they predate Rust. You can't just dereference NULLs or spray random memory and still "absolutely avoid crashes". If you let C code write past end of a vector, you will have an unstable system and data corruption. Catching these bugs before they cause damage is an improvement to stability. In Rust you can compartmentalize panics. Instead of messing up the whole kernel or causing a machine-halting kernel panic, you can gracefully unwind one call and execute a fallback or return an error code from the one syscall that hit the bug. That is how you can continue running the kernel reliably instead of hoping to get lucky. Then, there was a miscommunication between the Linux Rust project and Linus, about an issue that does not exist any more. An early draft had a handler that translated OOM to kernel panics as a kludge from use of Rust's standard library containers as a placeholder for proper containers being developed. Linus rightly criticized that this was a bad idea, but it was never meant to be the final setup. That code has been replaced now, and Rust in the kernel uses fallible allocation that does not abort nor panic. The issue does not exist in the no-alloc Rust dialect used in the kernel going forward.

selfmodruntime 4y ago
You are entirely correct.

brabel 4y ago

Wouldn't it be possible to make gcc (optionally?) add https://docs.rs/no-panic/latest/no_panic/ https://docs.rs/no-panic/latest/no_panic/ to every function it compiles? Sure, that may make most Rust code not compile, but for kernel devs, this may not be too much of a hindrance as they may only use a small subset of crates which could be all made compile with this option.

selfmodruntime 4y ago
If you read the caveats section of the crate, you will find that it is quite limited in its capabilities. I firmly believe that panic-free guarantees need to be built into the compiler with a special flag.