7 ms·

This may be a naive question, but I cannot help but wonder: As C and Rust aim to be link-compatible, wouldn't it be easier to gradually replace parts of the Lin

by krylon 5y ago

This may be a naive question, but I cannot help but wonder: As C and Rust aim to be link-compatible, wouldn't it be easier to gradually replace parts of the Linux kernel with Rust code? The only technical problem I can think of is that Rust may not be available for all CPU architectures Linux supports, but this is just speculation on my part having done no research on the matter.

gspr 5y ago
A practical problem is that in order to gain the benefit of linking Rust and C code, one has to give up Rust's wonderful guarantees at the interface. So until islands of Rust meet up, these interact through a C ABI, and have to expose C-like behavior.
- ls65536 5y ago
  But you still get those guarantees and benefits in the Rust implementation itself, even if not at the interface (to non-Rust code). By a similar argument, a standalone Rust program "gives up" its guarantees whenever the process makes a call to libc or to the operating system (syscalls), but this isn't really a practical problem.
  - gspr 5y ago
    Sure, I agree. The point is that if the total corpus of Rust code is too isolated into too small islands, then the boundary effects of each island may eat up a lot of the benefit. I still think the project is really cool and worthwhile.
- jll29 5y ago
  The world really needs _two_ projects, a practical one that is interoperable with the here and now, to get incremental improvements in security from bits reimplemented in Rust. And then, in the longer term, someone ought to write a book about operating system implementation in Rust that ignores Linux interoperability and focuses on readability, maintainability by showing use of Rust's idiomatic style.
wongarsu 5y ago
That's what may happen with the Linux kernel over time, now that it allows parts written in Rust. The limitation of that approach is that all internal interfaces (which includes most data structures) have to be C-compatible. You can get much of the safety benefits of Rust, but lose a lot of Rust's ergonomics.
- geewee 5y ago
  I don't think that the Linux kernel has decided (yet) to allow rust code into the kernel proper, has it?
  - fork-bomber 5y ago
    It hasn't. But the attitude towards using Rust for device driver development has now gotten very positive, especially post the recent kernel summit.
  - pjmlp 5y ago
    Google has decided to go forward anyway. Just like Android Linux compiles just fine with clang for the last five years or so, it now makes use of Rust. https://source.android.com/setup/build/rust/building-rust-modules/overview https://source.android.com/setup/build/rust/building-rust-mo... If upstream ever cares to support clang or Rust, that is another matter.
    - jstarks 5y ago
      Unless I'm missing something, that link refers to building Android user-mode components in Rust, not kernel components in Rust.
      - steveklabnik 5y ago
        That's correct, but it came after them rebuilding the bluetooth stack https://news.ycombinator.com/item?id=26647981 https://news.ycombinator.com/item?id=26647981
  - 5y ago
fork-bomber 5y ago
The Rust for Linux kernel project aims to enable writing Linux kernel device drivers in Rust. See: https://lwn.net/Articles/862018/ https://lwn.net/Articles/862018/ The issue of Rust's LLVM based compiler toolchain not targeting all CPU archs is intended to be solved by the gcc-rs project. See: https://lwn.net/Articles/871283/ https://lwn.net/Articles/871283/ I think the approach the Rust for Linux project is taking is wise: Not about outright re-writes but more about focusing on those subsystems where Rust's intrinsic safety and security properties helps the most.
- maleldil 5y ago
  Last I checked, one of the big problems was the Rust panics when you run out of memory, which is unacceptable in the kernel. Is there any progress on that?
  - jerven 5y ago
    Yes a lot. https://rust-for-linux.github.io/docs/alloc/alloc/index.html https://rust-for-linux.github.io/docs/alloc/alloc/index.html
  - tialaramex 5y ago
    Out of the box Rust doesn't provide any way to allocate heap memory, so, you can't run out if it. Your ordinary userspace apps use std (the standard library) which relies on the alloc crate, and that provides heap allocation which indeed panics if the allocation fails. Because it correctly guesses that your "clever" strategy to handle allocation failure actually isn't and will just triple fault anyway so it should cut to the chase. The kernel obviously doesn't have std, and Rust for Linux implements its own alloc crate. Linus' requirement that you can fail memory allocation just means all the calls in alloc that can actually allocate memory now return Result to indicate whether the allocation was successful. This isn't how you'd do things in userspace, but, this isn't userspace so fine.
    - abendstolz 5y ago
      Can you elaborate as to why "his isn't how you'd do things in userspace, but, this isn't userspace so fine" holds? Naive me - not a kernel dev at all - would argue that returning Result<Memory, AllocationError> is always better, even for userspace because it would allow me to additionally log something or gracefully deal with this. Even if I don't want to deal with it, I could just `.unwrap()` or `.expect('my error message')` it. Note: I am not trying to be snarky here, I genuinely don't know and would like to. If answering this is too complex, maybe you can point me in the right direction so I can ask the right questions to find answers myself? Thanks in any case!
phendrenad2 5y ago
The Linux kernel is massive, so writing any part of it in Rust is an enormous undertaking. Even a few functions at a time, we're talking decades.
- krylon 5y ago
  Well, writing a kernel from scratch that supports as many CPU architectures and devices as Linux would take about as long, assuming one could attract a critical mass of developers. Using an incremental approach at least gives us some benefits in the near future. I'm not even saying a fresh start would be a bad idea. But incrementally replacing parts of Linux seems like a more promising approach, IMHO.
pornel 5y ago
Yes, gradual replacement is easier and more practical for large projects. However, typical C APIs and idioms are different from idiomatic Rust. Rust uses more type-system features, generics, iterators, RAII, and prefers tree-like data structures and far fewer pointers (no linked lists!). C rewritten in Rust is still very C-like, and requires refactorings that you can't do until it's all Rust. BTW: There are two GCC-based Rust implementations in the works, so compatibility with exotic platforms is going to be solved.
amw-zero 5y ago
It’s not naive, it’s just been speculated and talked about incessantly since Rust came out. The one naive part is underestimating how long that would take - Linux is one of the largest codebases on Earth. It would require massive coordination over years to rewrite, and in the end all you would get is the exact same product. It’s just not an interesting or unique perspective, and pretty silly to suggest seriously.

by krylon 5y ago

gspr 5y ago

A practical problem is that in order to gain the benefit of linking Rust and C code, one has to give up Rust's wonderful guarantees at the interface. So until islands of Rust meet up, these interact through a C ABI, and have to expose C-like behavior.

ls65536 5y ago
But you still get those guarantees and benefits in the Rust implementation itself, even if not at the interface (to non-Rust code). By a similar argument, a standalone Rust program "gives up" its guarantees whenever the process makes a call to libc or to the operating system (syscalls), but this isn't really a practical problem.
- gspr 5y ago
  Sure, I agree. The point is that if the total corpus of Rust code is too isolated into too small islands, then the boundary effects of each island may eat up a lot of the benefit. I still think the project is really cool and worthwhile.
jll29 5y ago
The world really needs _two_ projects, a practical one that is interoperable with the here and now, to get incremental improvements in security from bits reimplemented in Rust. And then, in the longer term, someone ought to write a book about operating system implementation in Rust that ignores Linux interoperability and focuses on readability, maintainability by showing use of Rust's idiomatic style.

wongarsu 5y ago

That's what may happen with the Linux kernel over time, now that it allows parts written in Rust. The limitation of that approach is that all internal interfaces (which includes most data structures) have to be C-compatible. You can get much of the safety benefits of Rust, but lose a lot of Rust's ergonomics.

geewee 5y ago
I don't think that the Linux kernel has decided (yet) to allow rust code into the kernel proper, has it?
- fork-bomber 5y ago
  It hasn't. But the attitude towards using Rust for device driver development has now gotten very positive, especially post the recent kernel summit.
- pjmlp 5y ago
  Google has decided to go forward anyway. Just like Android Linux compiles just fine with clang for the last five years or so, it now makes use of Rust. https://source.android.com/setup/build/rust/building-rust-modules/overview https://source.android.com/setup/build/rust/building-rust-mo... If upstream ever cares to support clang or Rust, that is another matter.
  - jstarks 5y ago
    Unless I'm missing something, that link refers to building Android user-mode components in Rust, not kernel components in Rust.
    - steveklabnik 5y ago
      That's correct, but it came after them rebuilding the bluetooth stack https://news.ycombinator.com/item?id=26647981 https://news.ycombinator.com/item?id=26647981
- 5y ago

fork-bomber 5y ago

The Rust for Linux kernel project aims to enable writing Linux kernel device drivers in Rust. See: https://lwn.net/Articles/862018/ https://lwn.net/Articles/862018/ The issue of Rust's LLVM based compiler toolchain not targeting all CPU archs is intended to be solved by the gcc-rs project. See: https://lwn.net/Articles/871283/ https://lwn.net/Articles/871283/ I think the approach the Rust for Linux project is taking is wise: Not about outright re-writes but more about focusing on those subsystems where Rust's intrinsic safety and security properties helps the most.

maleldil 5y ago
Last I checked, one of the big problems was the Rust panics when you run out of memory, which is unacceptable in the kernel. Is there any progress on that?
- jerven 5y ago
  Yes a lot. https://rust-for-linux.github.io/docs/alloc/alloc/index.html https://rust-for-linux.github.io/docs/alloc/alloc/index.html
- tialaramex 5y ago
  Out of the box Rust doesn't provide any way to allocate heap memory, so, you can't run out if it. Your ordinary userspace apps use std (the standard library) which relies on the alloc crate, and that provides heap allocation which indeed panics if the allocation fails. Because it correctly guesses that your "clever" strategy to handle allocation failure actually isn't and will just triple fault anyway so it should cut to the chase. The kernel obviously doesn't have std, and Rust for Linux implements its own alloc crate. Linus' requirement that you can fail memory allocation just means all the calls in alloc that can actually allocate memory now return Result to indicate whether the allocation was successful. This isn't how you'd do things in userspace, but, this isn't userspace so fine.
  - abendstolz 5y ago
    Can you elaborate as to why "his isn't how you'd do things in userspace, but, this isn't userspace so fine" holds? Naive me - not a kernel dev at all - would argue that returning Result<Memory, AllocationError> is always better, even for userspace because it would allow me to additionally log something or gracefully deal with this. Even if I don't want to deal with it, I could just `.unwrap()` or `.expect('my error message')` it. Note: I am not trying to be snarky here, I genuinely don't know and would like to. If answering this is too complex, maybe you can point me in the right direction so I can ask the right questions to find answers myself? Thanks in any case!

phendrenad2 5y ago

The Linux kernel is massive, so writing any part of it in Rust is an enormous undertaking. Even a few functions at a time, we're talking decades.

krylon 5y ago
Well, writing a kernel from scratch that supports as many CPU architectures and devices as Linux would take about as long, assuming one could attract a critical mass of developers. Using an incremental approach at least gives us some benefits in the near future. I'm not even saying a fresh start would be a bad idea. But incrementally replacing parts of Linux seems like a more promising approach, IMHO.

pornel 5y ago

Yes, gradual replacement is easier and more practical for large projects. However, typical C APIs and idioms are different from idiomatic Rust. Rust uses more type-system features, generics, iterators, RAII, and prefers tree-like data structures and far fewer pointers (no linked lists!). C rewritten in Rust is still very C-like, and requires refactorings that you can't do until it's all Rust. BTW: There are two GCC-based Rust implementations in the works, so compatibility with exotic platforms is going to be solved.

amw-zero 5y ago

It’s not naive, it’s just been speculated and talked about incessantly since Rust came out. The one naive part is underestimating how long that would take - Linux is one of the largest codebases on Earth. It would require massive coordination over years to rewrite, and in the end all you would get is the exact same product. It’s just not an interesting or unique perspective, and pretty silly to suggest seriously.