Rust-for-Linux
mosys | Rust-for-Linux | |
---|---|---|
1 | 84 | |
- | 4,118 | |
- | 2.0% | |
- | 0.0 | |
- | about 13 hours ago | |
C | ||
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mosys
Rust-for-Linux
- Rewriting Rust
-
Committing to Rust in the Kernel
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
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
They say that they're committed to getting this stuff done, and in particular: 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.
-
Deploying Rust in Existing Firmware Codebases
The goal of rust for linux isn't to wholesale translate linux into rust, but simply to be able to write pieces of linux (largely new ones) in rust. I think it's very unlikely anyone (including google) will take on a wholesale translation anytime soon. That said
> It's unlikely that Google has much sway here
Google has helped fund the rust for linux project pretty much from the start [1], they're one of three organizations mentioned on the homepage due to their sponorship [2]. They're actively involved in it, and have already ported their android "binder" driver into it with the intent to ship it in android. This strikes me as a very weird take.
[1] https://www.memorysafety.org/blog/supporting-miguel-ojeda-ru...
[2] https://rust-for-linux.com/
- Rust for Linux
-
The Linux Kernel Prepares for Rust 1.77 Upgrade
Rust is backwards compatible when you stick to stable features, but the kernel uses unstable features that can and do incur breaking changes.
https://github.com/Rust-for-Linux/linux/issues/2
- Rust in Linux Kernel
-
Mark Russinovich: “Working towards enabling Windows driver development in Rust”
> How would this work?
Don't know exactly what you're asking.
> And why would it be a better idea?
Poorly written device drivers are a significant attack vector. It's one of the reasons Linux is now exploring using Rust for its own device drivers.[0] You may be asking -- why Rust and not some other language? Rust has many of the performance and interoperability advantages of C and C++, but as noted, makes certain classes of memory safety issues impossible. Rust also has significant mindshare among systems programming communities.
[0]: https://rust-for-linux.com
- The Linux Kernel Module Programming Guide
- Teknisk karrierevej i Danmark som softwareudvikler
-
The state of Flatpak security: major Projects are the worst?
Rust-for-Linux issue tracker
What are some alternatives?
smoltcp - a smol tcp/ip stack
rustig - A tool to detect code paths leading to Rust's panic handler
kerla-demo - ssh://demo.kerla.dev
rfcs - RFCs for changes to Rust
headcrab - A modern Rust debugging library 🦀
jakt - The Jakt Programming Language