5 ms·

Shouldn't this also be a much larger problem when deploying rust on embedded systems or in the kernel? How is that solved in these cases? Or is this not a probl

by nikeee 4y ago

Shouldn't this also be a much larger problem when deploying rust on embedded systems or in the kernel? How is that solved in these cases? Or is this not a problem at all?

tasn 4y ago
Both the kernel and embedded systems manage memory very differently to "normal" applications. The kernel has its own allocation functions, and embedded systems often don't "allocate" but rather just have fixed memory regions they use for things.
- nikeee 4y ago
  I recall from playing with Arduino that using heap-allocated strings will cause heap fragmentation, which is why they should be avoided. This was C++, doesn't this count for rust as well? Do kmalloc/kzmalloc do magic to circumvent this problem, similar to jemalloc?
Tuna-Fish 4y ago
Rust by default uses the platform allocator. Anything that's true of it's allocator performance is also true of C. Also, as the sibling comment said, when you are doing tight embedded, the solution is not to allocate things dynamically.
- mr_00ff00 4y ago
  I’m curious when not allocating things dynamically, does that just get around all memory safety (other than temporal with array bounds checking). Essentially any language that does array bounds checking would be as safe as rust? Or am I missing anything? C does not technically do that, so rust is still safer. But zig would be the same in the embedded space as rust? Or is there anything I am missing?
  - pdimitar 4y ago
    Rust's compiler also makes sure you never modify a place in memory from more than one place.
    - mr_00ff00 4y ago
      That’s true, but that would be fairly trivial to do in a C program with only stack variables. Just always have only 1 mutable reference. Something like C++ or Zig could enforce those rules even more easily.
      - pdimitar 4y ago
        Yeah, I don't disagree. Shame they never went direction and instead were like "REAL MEN DON'T PROTECT AGAINST BUGS! WE DON'T WRITE BUGS!". But oh well. That's why we have the more modern languages these days.
steveklabnik 4y ago
The embedded code I write doesn’t use an allocator at all, so it’s not a problem there.
- scoutt 4y ago
  The day I started (time ago) to learn Rust I had trouble learning to map Error(s) and dynamic dispatching. My first thought was: "if I cannot escape dynamic dispatching (for example with crates that use it), I will never understand how to use Rust in embedded, because of Box<T>". And as an embedded C developer, this is something I never understood. For example: "Values can be boxed (allocated on the heap) by creating a Box<T>" (https://doc.rust-lang.org/rust-by-example/std/box.html https://doc.rust-lang.org/rust-by-example/std/box.html) But then I see Box<dyn std::error::Error> everywhere, for example in https://github.com/oxidecomputer/hubris/search?q=dyn https://github.com/oxidecomputer/hubris/search?q=dyn Is Box really allocating here? Is the "Rust By Example" text incomplete? Then I had to stop learning Rust for other reasons, but this doubt really hit me at the time.
  - jmillikin 4y ago
    Dynamic dispatch (the `dyn` keyword) and dynamic allocation are distinct in Rust. You'll see Box<dyn SomeTrait> a lot in application-level code because the developer UX of boxed dynamic resembles a GC'd language like Java/Go, but they're not really coupled under the hood. Dynamic dispatch allows you to call trait methods on values without knowing the concrete type of that value, similar to C++ virtual methods or a C-style manually constructed vtable. In an embedded context this will mostly show up as function parameters, since you can't move things around on the stack without knowing their size. You might also see references to a dyn value, like `&dyn SomeTrait` -- this is similar to `Box<dyn SomeTrait>`, but is a borrowed reference and therefore doesn't imply allocation. Your link to the Oxide Hubris repo is misleading you because the hits seem to be pretty much all in build-time helper scripts (`build.rs`) and other minor tooling. You'd want to look through the source of their main binary, which probably wouldn't use allocation just for error propagation.
    - 4y ago
cozzyd 4y ago
Same way you solve it in C. Don't use the heap.

by nikeee 4y ago

Shouldn't this also be a much larger problem when deploying rust on embedded systems or in the kernel? How is that solved in these cases? Or is this not a problem at all?

tasn 4y ago

Both the kernel and embedded systems manage memory very differently to "normal" applications. The kernel has its own allocation functions, and embedded systems often don't "allocate" but rather just have fixed memory regions they use for things.

nikeee 4y ago
I recall from playing with Arduino that using heap-allocated strings will cause heap fragmentation, which is why they should be avoided. This was C++, doesn't this count for rust as well? Do kmalloc/kzmalloc do magic to circumvent this problem, similar to jemalloc?

Tuna-Fish 4y ago

Rust by default uses the platform allocator. Anything that's true of it's allocator performance is also true of C. Also, as the sibling comment said, when you are doing tight embedded, the solution is not to allocate things dynamically.

mr_00ff00 4y ago
I’m curious when not allocating things dynamically, does that just get around all memory safety (other than temporal with array bounds checking). Essentially any language that does array bounds checking would be as safe as rust? Or am I missing anything? C does not technically do that, so rust is still safer. But zig would be the same in the embedded space as rust? Or is there anything I am missing?
- pdimitar 4y ago
  Rust's compiler also makes sure you never modify a place in memory from more than one place.
  - mr_00ff00 4y ago
    That’s true, but that would be fairly trivial to do in a C program with only stack variables. Just always have only 1 mutable reference. Something like C++ or Zig could enforce those rules even more easily.
    - pdimitar 4y ago
      Yeah, I don't disagree. Shame they never went direction and instead were like "REAL MEN DON'T PROTECT AGAINST BUGS! WE DON'T WRITE BUGS!". But oh well. That's why we have the more modern languages these days.

steveklabnik 4y ago

The embedded code I write doesn’t use an allocator at all, so it’s not a problem there.

scoutt 4y ago
The day I started (time ago) to learn Rust I had trouble learning to map Error(s) and dynamic dispatching. My first thought was: "if I cannot escape dynamic dispatching (for example with crates that use it), I will never understand how to use Rust in embedded, because of Box<T>". And as an embedded C developer, this is something I never understood. For example: "Values can be boxed (allocated on the heap) by creating a Box<T>" (https://doc.rust-lang.org/rust-by-example/std/box.html https://doc.rust-lang.org/rust-by-example/std/box.html) But then I see Box<dyn std::error::Error> everywhere, for example in https://github.com/oxidecomputer/hubris/search?q=dyn https://github.com/oxidecomputer/hubris/search?q=dyn Is Box really allocating here? Is the "Rust By Example" text incomplete? Then I had to stop learning Rust for other reasons, but this doubt really hit me at the time.
- jmillikin 4y ago
  Dynamic dispatch (the `dyn` keyword) and dynamic allocation are distinct in Rust. You'll see Box<dyn SomeTrait> a lot in application-level code because the developer UX of boxed dynamic resembles a GC'd language like Java/Go, but they're not really coupled under the hood. Dynamic dispatch allows you to call trait methods on values without knowing the concrete type of that value, similar to C++ virtual methods or a C-style manually constructed vtable. In an embedded context this will mostly show up as function parameters, since you can't move things around on the stack without knowing their size. You might also see references to a dyn value, like `&dyn SomeTrait` -- this is similar to `Box<dyn SomeTrait>`, but is a borrowed reference and therefore doesn't imply allocation. Your link to the Oxide Hubris repo is misleading you because the hits seem to be pretty much all in build-time helper scripts (`build.rs`) and other minor tooling. You'd want to look through the source of their main binary, which probably wouldn't use allocation just for error propagation.
  - 4y ago

cozzyd 4y ago

Same way you solve it in C. Don't use the heap.