A pair of Linux kernel modules using Rust

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • Zigi - Close all those tabs. Zigi will handle your updates.
  • Scout APM - Truly a developer’s best friend
  • SonarLint - Clean code begins in your IDE with SonarLint
  • InfluxDB - Build time-series-based applications quickly and at scale.
  • Rust-for-Linux

    Adding support for the Rust language to the Linux kernel. (by Rust-for-Linux)

    https://github.com/Rust-for-Linux/linux/blob/459035ab65c0ebb...

    So accessing an array out of bound will have a runtime check that will call the panic handler, and that panic handler calls BUG() which means kernel panic.

  • Zigi

    Close all those tabs. Zigi will handle your updates.. Zigi monitors Jira and GitHub updates, pings you when PRs need approval and lets you take fast actions - all directly from Slack! Plus it reduces cycle time by up to 75%.

  • absolution

    "Freedom from syn": Proc macro tools for operating on token trees (by Manishearth)

    > That probably will never compile especially quickly.

    Can you link the code? Proc macros are not inherently slow to compile, but most proc macros pull in the `syn` and `quote` crates for convenience, which are fairly heavyweight (and then most people experience proc macros most commonly via Serde, which is doing a ton of work on its own). In simple cases you can forego most of that work, and some libraries like https://github.com/Manishearth/absolution exist as lightweight alternatives in these cases. Depending on what the Asahi driver needs it could also benefit from something like this (although I'm not sure why it would need proc macros when it sounds like conditional compilation via `cfg` would suffice there).

  • no-panic

    Attribute macro to require that the compiler prove a function can't ever panic

    Because it's convenient and familiar to most programmers. Not providing bounds-checked indexing makes some kinds of code very hard to write.

    But note his problem also happens with integer division.

    In Rust, a[x] on an array or vec is really a roughly a shortand for a.get(x).unwrap() (with a different error message)

    Likewise, a / b on integers is a kind of a shortand for a.checked_div(b).unwrap()

    The thing is, if the index ever is out of bounds, or if the denominator is zero, the program has a bug, 100% of time. And if you catch a bug using an assertion there is seldom anything better than interrupting the execution (the only thing I can think of is restarting the program or the subsystem). If you continue execution past a programming error, you may sometimes corrupt data structures or introduce bizarre, hard to debug situations.

    Doing a pattern match on a.get(x) doesn't help because if it's ever None (and your program logic expects that x is in bounds) then you are kind of forced to bail.

    The downside here is that we aren't catching this bug at compile time. And it's true that sometimes we can rewrite the program to not have an indexing operation, usually using iterators (eliding the bounds check will make the program run faster, too). But in general this is not possible, at least not without bringing formal methods. But that's what tests are for, to ensure the correctness of stuff type errors can't catch.

    Now, there are some crates like https://github.com/dtolnay/no-panic or https://github.com/facebookexperimental/MIRAI that will check that your code is panic free. The first one is based on the fact that llvm optimizations can often remove dead code and thus remove the panic from a[x] or a / b - if it doesn't, then compilation fails. The second one employs formal methods to mathematically prove that there is no panic. I guess those techniques will eventually be ported to the kernel even if panics happen differently there (by hooking on the BUG mechanism or whatever)

  • MIRAI

    Rust mid-level IR Abstract Interpreter

    Because it's convenient and familiar to most programmers. Not providing bounds-checked indexing makes some kinds of code very hard to write.

    But note his problem also happens with integer division.

    In Rust, a[x] on an array or vec is really a roughly a shortand for a.get(x).unwrap() (with a different error message)

    Likewise, a / b on integers is a kind of a shortand for a.checked_div(b).unwrap()

    The thing is, if the index ever is out of bounds, or if the denominator is zero, the program has a bug, 100% of time. And if you catch a bug using an assertion there is seldom anything better than interrupting the execution (the only thing I can think of is restarting the program or the subsystem). If you continue execution past a programming error, you may sometimes corrupt data structures or introduce bizarre, hard to debug situations.

    Doing a pattern match on a.get(x) doesn't help because if it's ever None (and your program logic expects that x is in bounds) then you are kind of forced to bail.

    The downside here is that we aren't catching this bug at compile time. And it's true that sometimes we can rewrite the program to not have an indexing operation, usually using iterators (eliding the bounds check will make the program run faster, too). But in general this is not possible, at least not without bringing formal methods. But that's what tests are for, to ensure the correctness of stuff type errors can't catch.

    Now, there are some crates like https://github.com/dtolnay/no-panic or https://github.com/facebookexperimental/MIRAI that will check that your code is panic free. The first one is based on the fact that llvm optimizations can often remove dead code and thus remove the panic from a[x] or a / b - if it doesn't, then compilation fails. The second one employs formal methods to mathematically prove that there is no panic. I guess those techniques will eventually be ported to the kernel even if panics happen differently there (by hooking on the BUG mechanism or whatever)

  • Scout APM

    Truly a developer’s best friend. Scout APM is great for developers who want to find and fix performance issues in their applications. With Scout, we'll take care of the bugs so you can focus on building great things 🚀.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts