Concerns about embedded real time linux using rust

help
1

Hi, my name is Donald Murray, and Im new to this forum. I got my BSEE degree from UCD, Dublin, Ireland in 1982. I also was a professional experienced software engineer when I graduated with my engineering degree. Ive been living in Portland Oregon since 1982. These days i work mostly in embedded systems. Ive been working in high tech for about 45 years. Anyways, i am not fully up to speed with the rust language yet (its on my list). Ive worked with embedded linux in the past. Mostly i prefer not to use linux as the hardware to support it is more expensive. When i do use it, its to get free drivers :-). I just recently took a gander and noticed that people were usimg rust in drivers and threatening to put it in the kernel.

I have some major concerns...please correct me if i am wrong, as im not yet an expert in rust.

  1. You are going to need a rust to c converter, as rust compilers may not be available for every microcontroller like C is.
  2. I hear the reason for all this is rusts ability to handle memory leaks. Memory leaks are pretty simple to handle using counters. I know people leave bugs like this all the time, but its because they dont know how to encapsulate their allocations and frees. Bottom line i dont think we need a new language for this.
  3. Memory fragmentation is a bigger problem in all embedded systems, and if i understand it, rust doesnt help much with this. In fact, with embedded systems, i typically dont use alloc/free, but design the system to use arrays of objects and assign these objects to which subsystem requests them and frees them in their array when no longer needed. I am in control of all memory operations as part of my system design. My cable tv company did not have my experience, which is why it has to reboot once day.
  4. I have concern if rust is doing garbage collection in the background and not under my control. Doesnt this make linux less suitable for hard real time applications due the background processing?

I didnt know who was best to ask about these issues. I figured you probably heard similar issues already.

I would be so grateful if you could give this message to someone who is very experienced in embedded development who is working on the linux rust integration, and if they could address my concerns.

As i said, im not a rust expert, but have only quickly looked at the language. Indeed the answers to these questions will determine how deep ill dive into rust.

Again, thank you so much for taking the time.

-Donald Murray, BSEE

2 Likes
2

I have not personally tinkered with the Rust-for-Linux project, but I will try to give you some reassuring information:

You are going to need a rust to c converter, as rust compilers may not be available for every microcontroller like C is.

It is very unlikely that that will happen. I don't know what will, but the current situation is that you can write some limited kernel modules in Rust but the kernel itself is not going to contain Rust any time soon. So the worst likely case is “If rustc doesn't support your platform, you can't use some newer drivers”. Or perhaps rustc will gain more platform support, or GCC-Rust will become a usable compiler and support every target GCC does.

I hear the reason for all this is rusts ability to handle memory leaks. Memory leaks are pretty simple to handle using counters. I know people leave bugs like this all the time, but its because they dont know how to encapsulate their allocations and frees.

The premise for Rust is very much we need to stop having those bugs. Empirically, people make mistakes like this too often, and they are not always about leaks — sometimes they are about use-after-free that creates security bugs and crashes. Rust's design is focused on statically (not with run-time checks) preventing all of this class of bugs from happening.

Memory fragmentation is a bigger problem in all embedded systems, and if i understand it, rust doesnt help much with this. In fact, with embedded systems, i typically dont use alloc/free, but design the system to use arrays of objects and assign these objects to which subsystem requests them and frees them in their array when no longer needed. I am in control of all memory operations as part of my system design.

You can write this type of program in Rust if you wish. Rust is not different from C in this regard; and embedded systems are one of the fields Rust does wish to support well.

I have concern if rust is doing garbage collection in the background and not under my control.

Rust has no garbage collector! The only thing Rust does is provide compile-time checks that help you correctly perform reference counting, and then only if you ask for reference counting. The majority of Rust's support for memory safety comes via its “references” which are not counted but verified at compile-time to not outlive the thing they refer to.

In fact, Rust is very specifically designed so that it “has no runtime” (or rather, no more than C does). There is (almost) no overhead that you don't opt in to.

11 Likes
3

  1. There is mrustc that can compile Rust code to C, but I don't think it's used in production. Mostly people just choose Rust for hardware that LLVM already supports. There is GCC-based Rust backend in the works, so eventually Rust will support all platforms that GCC supports.

  2. This is not correct. While Rust generally helps with cleanup, that's not the main focus. Rust has guarantees around memory safety, such as use-after-free bugs, buffer overflows, data races across threads. It also helps with issues like iterator invalidation. Generally the focus is memory corruption. Rust's guarantees also work for data on the stack.

  3. Rust supports custom allocators. You can also use arenas/pools and other design patterns that prevent fragmentation. Rust has explicit control over allocations, and idiomatic Rust uses stack a lot, which helps avoid small objects on the heap. Rust's data types support being moved to a different memory address, but there's no GC, so there's no automatic compaction.

  4. Rust does not have garbage collection. There is no background process. Rust manages memory via static analysis, at compile time. It basically looks at the source code and inserts free() where necessary, like a C programmer would.

7 Likes
4

Thank you for your response, so im now interested in learning rust in more detail. Thx again. -D

6

Thanks for the prompt response...much appreciated.

7

Oh my dear.

We have decades of collective experience to prove that this is simply false. Even folks who know how to encapsulate their mallocs and frees write accidental leaks, or worse yet, exploitable use-after-free or double-free bugs. One can have 45 years of experience and a degree from UCD and still write memory management bugs in C. And people do, all the time. We did need a new language for safety, because C and C++ code is the cause of a lot of avoidable errors.

Rust isn't doing any "garbage collection in the background", whatever you mean by it. Rust applies scoped resource management, like C++'s RAII. There is no implicit heap allocation, no implicit pointers, and destruction of values is deterministic and predictable.

2 Likes
8

Im most recently concerned where people developing embedded code using malloc. This is guaranteed to produce fragmentation over time. Im unsure that there is any way to avoid that if you use malloc at all.

9

Just like in C++ and C, you don't need to make allocations with the global allocator if you don't want to.

Rust has crates for arena allocators and so on, but you can also "just" write code that doesn't make allocations. For example, I've worked on a couple projects on microcontrollers where we didn't pull in the allocator at all. It's a slightly less convenient way to write code, but you can definitely restrict yourself to buffers on the stack and static variables if you want to avoid fragmentation.

2 Likes
10

If you write code without malloc, why use rust at all? That is my uktimate question.

11

Just because there is no malloc does not mean there are no pointers, and Rust's safety properties apply just as much to references/pointers into the stack or static memory just as they do for heap allocations.

5 Likes
12

Since it hasn't been said before, there is an important distinction that needs to be addressed. For anyone who has been doing embedded work for any length of time and hasn't yet been exposed to Rust, the only thing that can really be said is that the language is entirely unlike everything you've experienced before. There is just nothing comparable, and the only way to rationalize questions like why use Rust at all is to put some honest effort into learning and using it.

Hearing things like "it's a bit like C++ except it's memory safe and thread safe, and it's actually practical to build kernels with it" will not sound convincing. You have to see it to believe it.

It's as if you've spent an entire career writing assembly, and one day you hear something or other about a brand-new programming language claiming to be a "portable assembler" called C. It sounds too good to be true. And then the years pass, and all of the mystery and disbelief gives way to obviousness and precision engineering. That's sort of how it is when going from C to Rust.

If you are genuinely interested, here are some resources to get you started:

12 Likes
13

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.