Rust-for-Linux
rustc_codegen_gcc
Rust-for-Linux | rustc_codegen_gcc | |
---|---|---|
84 | 33 | |
4,220 | 11 | |
0.3% | - | |
0.0 | 9.6 | |
7 days ago | 7 months ago | |
C | Rust | |
GNU General Public License v3.0 or later | Apache License 2.0 |
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.
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
rustc_codegen_gcc
- Rust Support in the Linux Kernel
-
GCC Rust Monthly Report #9 August 2021
It's true that if this project succeeds, that would be an outcome, but it's probably worth noting that you'd really only have to add support for the GCC backend to do that, and not reimplement the frontend as well (parsing, type checking, lifetime checking, etc.). There's an unrelated project working to do that: https://github.com/antoyo/rustc_codegen_gcc that would likely yield those same benefits for less effort.
-
Gentoo be like :
platform support (may improve soon)
-
Recursive fib is faster in C++?
Here's the gcc backend for rustc here https://github.com/antoyo/rustc_codegen_gcc Since this just swaps the optimizer/codegen module and reuses all the other stuff from rustc it needs less work and can already compile many valid rust programs.
-
Anyone used the gcc backend before?
I'd like to use the rustc_codegen_gcc backend to compile some Rust programs, but I'm confused about how to install and use the patched libgccjit dependency. I've downloaded the fork provided but don't know where to go from there.
-
The Tor Project announces Arti, a Tor implementation written in Rust from scratch
I was being a little sloppy and mixing together "actual embedded hardware" with "extensions for applications written in other languages" in my head. I think your point about LLVM is still accurate, though I hear peeps about different projects working on GCC support from time to time.
-
Rust GCC back end was officially accepted into the compiler
This doesn't have anything to do with using GCC to compile rust, but instead using rustc to compile Rust using the GCC backend. You can do that today by using the linked project, rustc_codegen_gcc, which is intended to be integrated into rustc at some point in the (hopefully near) future.
-
This is the patch series to add support for Rust as a second language to the Linux kernel.
Rather than mrustc you should probably look at rustc_codegen_gcc which uses gcc as a backend to rustc (WIP) or GCC Rust which tries to implement a rust frontend for gcc (also WIP). I think rustc_codegen_gcc looks the most promising at the moment
-
Hacker News top posts: Jul 6, 2021
Libgccjit AOT Codegen for Rustc\ (2 comments)
- Libgccjit AOT Codegen for Rustc
What are some alternatives?
rustig - A tool to detect code paths leading to Rust's panic handler
gcc-rust - a (WIP) Rust frontend for gcc / a gcc backend for rustc
gccrs - GCC Front-End for Rust
ttapi - Golang Turntable.fm api
rfcs - RFCs for changes to Rust