To be honest, I don't think Linux being the "One True Kernel" is really worthwhile, and the benefits of adding Rust to the kernel outweigh the downsides.
There are plenty of other kernels available for embedded work, and my understanding of Rust in the Linux kernel is that it's mostly drivers, which seems like it would be optional for your use case.
That said, I've not done much embedded, I may be misunderstanding something.
Rust on embedded seems a hell of a lot more viable for large, complicated projects. You can basically use the entire standard library (sans io and alloc, obviously).
Not exactly embedded but I'm writing an operating system kernel in Rust, having done so previously with C.
I love it so far. There are still some rough edges in the tooling, but overall I'm very happy. The resulting binaries are much larger than C projects, but I'm also opting into a lot of functionality you probably wouldn't always need in smaller environments.
I'm latching onto a non-main argument to be pedantic, but I'd like to mention that Rust is fine for _non-embedded_ kernel development too, in my experience.
As you're likely aware, Rust for embedded sucks when there's no HAL, but should be pretty pleasant otherwise. Have you looked into the cortex-a[1] crate?
Some unnecessary instructions could also be a part of an ongoing optimization effort[2][3].
A best feature it may well be, but it requires infrastructure and the OS kernel provides that infrastructure it doesn't depend on it.
Rust for Linux relies on the fact that Rust is deliberately structured in layers so that the bottom layer doesn't need that infrastructure, this was needed to make embedded Rust practical, but it's also important for Linux. Actually, Linux needs even more than Rust had initially, but that's driven further improvements to Rust itself.
You could add a layer to do all this lifting (that's what e.g. a Java OS does) but that's not going to fly in Linux, which is one reason why Go for Linux isn't a thing whereas Rust for Linux is.
Yes. In fact, the Linux kernel has been talking about allowing drivers to be written in Rust. (There are other examples of stuff in this space too, but that's the biggest deal so far.)
Rust is not a good match for embedded Linux so long as binary sizes are so gigantic (same is true for a lot of C++). When your binary takes 100 MB of a few GB emmc, you have a problem.
I've found the Rust embedded tooling is equivalent on Windows and Linux. Ie the same tools and programs work, and in (almost) the same way. More broadly, Windows is more popular for embedded. My anecdote here is limited to Cortex-M.
Erm, Rust-as-designed may or may not be suited for embedded, but Rust-as-it-is-now has some nasty limitations - not the least of which is the lack of support for anything that is not ARM.
The productiveness, safety, and beauty (seriously!) of the surprisingly numerous Rust kernel and embedded projects suggests otherwise. That use case took off very quickly in Rust world.
I was slightly confused by your comment; then I realized: when you say "kernel" you mean Linux, specifically. Rust can very much be used to write kernels!
IMHO the entire Linux kernel should be rewritten as a microkernel in Rust. Another option would be to use the seL4 kernel and salvage parts of Linux to become device drivers and services.
There are plenty of other kernels available for embedded work, and my understanding of Rust in the Linux kernel is that it's mostly drivers, which seems like it would be optional for your use case.
That said, I've not done much embedded, I may be misunderstanding something.
reply