Re:Announcing Rust 1.0
by mastax on Friday May 15, 2015 @04:28PM
(#9553463)
The story for rust in embedded contexts is not quite finished. There are dozens of people writing kernels in rust, there's zinc for arm microcontrollers and I've seen projects for raspi and PSX, so stuff works. It's not great yet, though. Once the allocator api is added to the stdlib it'll be much easier to use the standard library in embedded contexts. There's probably other stuff I don't know about but I know for sure that this is a priority for the near future.
[ Parent
| on HN ]
My current approach to the heap problem (I'm working on a toy Rust kernel) is to compile the allocator portions of the standard library (liballoc) with a configuration flag that makes them use a particular set of external functions as the low-level heap allocation machinery. Then, my kernel provides these functions, and all the nice stuff (Box, Vec, etc.) "just works".
IF you're curious, the relevant code is at https://github.com/krzysz00/rust-kernel/blob/master/kernel/m... . The functions that start with "rust_" are the allocator interface
Couldn't help but notice,
F' as u8
is equivalent to b'F'
, and ['F' as u8, 'R' as u8, 'E' as u8, 'E' as u8]
is equivalent to *b"FREE"
which definitely is a lot more concise :). These are called byte string literals.Edit: The dereference is necessary because b"FREE" on its own has the type &[u8; 4].
That's much easier than I thought it was! I'll have to start working on my kernel again.
You can find some more {complex, idiomatic, not terribly hacked together} Rust kernels at https://github.com/thepowersgang/ .
Very interesting. Thank you for sharing. Would it be too much to ask for more?
I'm not sure what you're getting at. More of what?
Share more of experience with Rust. :)