Lately I have been playing around and trying to learn the rust language, but it gets really annoying having to include all the rust toolchain and pushing 900MB+ container images to my raspberry pi’s. So I created this little template project I call RoaaR - Rust on an Armv7 ResinOS (amazing, grammatically correct name, I know). What RoaaR does is to allow you to cross compile your rust code in a container locally on your laptop and then spit that compiled binary into a really small container that we end up shipping to either a local resinOS device or a fleet of resin.io managed devices. This also has the added benefit of only pushing your compiled binary to the end devices, just in case you are worried about people stealing your super sweet sauce code
Currently RoaaR can do two different things at the compile stage, 1.) it will cross-compile your rust src in an x86 container, this works great if you are writing pure rust code and don’t need to link to any of those pesky unsafe C libraries using the FFI.
If you are one of the unlucky ones, like myself who needs to link against something like libspotify so I can use the rustify crate, then you can pass the --unsafe option to the build.sh and your code will get built in an QEMU emulated container on your laptop. This allows you can install some stuff, like libspotify so your code is built and linked properly and you dont have to worry too much about sys_roots and that kinda jazz.
Currently RoaaR is still pretty rough (as most Friday Hacks are) but it does end up producing some pretty minimal rust based containers. My super simple starting example produces an image which is 21.53MB on disk. We can definitely make it smaller if we use FROM scratch, but I prefer having a bit of a file system and a few utilities, so I usually opt for a small Alpine linux base.
followed the README to run build.sh, commit the relevant changes and binaries, and push to Raspberry Pi 3.
Super quick to upload and deploy to the devices as well indeed (haven’t tried the unsafe version yet). Added the code to resin-io-playground/resin-rust-blinkt, just fyi.
I know it’s not very crucial, but I was thinking it would be nice someone to have the project name not hard-wired (as it is my_project at the moment, due to Cargo.toml and the build scripts), but it’s not too big of a deal for changing it manually.
Another (kinda related) thing is, what do you think, could this project be modified such that the whole project source would live in a subdirectory (not just the src as it is now, but Cargo.toml and anything that is the code that one deploys, and not the tools to deploy it)? If it’s a subdir, then it could be used to pull in rust project just as git submodules, or unpacking a normal rust project structure in a directory. I’m guessing it wouldn’t need too much adjustment. (does this question make sense?
Anyway, I know now what am I going to use if I use rust on arm next time for sure, cheers!
Hey @imrehg glad you got a chance to test it out. After I built it, I actually went out and looked for other solutions and am now looking at https://github.com/japaric/cross which is really, really nice for pure rust projects (I am still working out how I can use it with dynamically linked libraries). You can see how I am using the cross here in my raspberry pi senseHat crate I started working on. I think it should cover the use cases you described. I have also been playing around with https://github.com/dlecan/rust-crosscompiler-arm which is a nice solution aswell
Something I want to put on your radar, since you seem potentially interested, is that a coworker and I ( @ https://tulip.co ) have a little (pretty back-burner unfortunately) project to prototype running some of our stuff on ResinOS using Chef’s habitat.sh toolchain for builds and supervision. (The connection to this thread, if its not obvious, is that the entire habitat project is all rust)
I talked to some of the Habitat folks at a meetup and they are really interested in proving out habitat in the IoT space but haven’t had many opportunities yet. We started a #iot channel on habitat’s slack team and it has pretty good membership, but has not been super active so far. I’d encourage you to join us
Adam Jacob (Chef’s CTO) pointed out that y’all’s (Resin’s) president is a former Chef, so I really think there is good potential here for collaboration and (dare I stoop to this word choice) corporate synergy
The habitat supervisor definitely is duplicating a decent chunk of what Resin’s supervisor does; I kinda lost track of what was happening with the golang version of y’all’s supervisor, but I think habitat could be a good alternative for people if they want something a little more operationally predictable than coffescript/node.
And (as primarily a sysadmin type day-to-day my primary interest), I think there is a lot to be said for potentially having a common toolchain & workflow across the IoT and ~datacenter-scale compute solutions like kubernetes.
Anyway, just wanted to see if you were potentially interested
Hey @donaldguy this sounds very cool and habitat.sh looks like an interesting project, so I have joined the slack team to keep in the loop on this and help out where I can. My rust capabilities are very nascent to say the least We are on a path to convert much of our OS stuff to rust, so its always interesting to see projects like this.
By the way tulip.co looks very cool. I assume you have looked around and played with resin.io a bit as an option. Would love to know your thoughts on it
I’ve been playing with