Revisiting Hubris appconfigs - Cliffle
So in my day-job over at Oxide we’ve built this nice embedded operating system called Hubris. If you follow my blog, you’re probably aware of it.
I also build a lot of embedded electronics outside my day-job, and people sometimes ask me (often excitedly!) if they’re using Hubris.
The answer so far is “no.” This is for a variety of reasons, but probably the biggest: it’s actually quite difficult to use Hubris for anything if you don’t want your code to live in the Oxide Hubris repo!
I would like to fix this, to enable other teams to use Hubris without having to coordinate with Oxide (or even publish their source code!). I’m starting by trying to address the needs of a single friendly customer: me.
As of this week I have it working, in a set of tools I call exhubris. It’s not by any means done (or all that pleasant to use). I’m going to write some posts about it, to help me think through the design process, and (more importantly!) to solicit feedback from my readers on where they think things should go.
The details of the system have changed a lot over the past four years, but the basic design is still what I described in my announcement talk. A Hubris application is a firmware image intended to be flashed onto some microcontroller; it is made up of the Hubris kernel and a collection of (application-chosen) tasks. The kernel and each task are all compiled separately, and isolated from one another using hardware memory protection. As a result, while we benefit from Rust’s memory safety, we don’t rely on it for system correctness.
