In general we plan on making the system as open sourced as we possibly can, so there's no specific thought currently being put into closed source tasks. While it could work, the build system doesn't actually support that at all right now.

I assumed you guys wouldn't do this, but thought this could lead to a larger adoption in this space.

Alternatively I thought maybe you needed to have some closed source component from a vendor and could only include it like that.

Yeah, I hear you on the adoption thing for sure, though to be honest, right now we are laser focused on shipping Oxide's product, and so if nobody else but us uses Hubris, that is 100% okay. As our CONTRIBUTING.md mentions, we aren't yet at the stage where we're trying to grow this as an independent thing.

It's true that vendors are likely to be an area where we have to deal with some things being closed source, though we're not simply accepting that as a given. This is one reason we're writing so much of our own software, and also, poking at the bits that must remain closed: https://oxide.computer/blog/lpc55

I definitely didn't mean it as a feature request - blobs aren't actually that common in embedded (esp32 and some motor driver libraries are the most common exceptions), so I don't think it's important for adoption. In fact, not supporting it enables future ergonomics improvements and code sharing between tasks, so I appreciate that it's not a driving factor in the design.

> esp32 and […] are the most common exceptions

Well, nearly anything having to do with wireless is typically blobs :/

Even Nordic has blobby SoftDevices, though you don't have to use them since Apache NimBLE exists (and rubble in Rust though that's only usable for advertising-only for now).

Now that it's open, how open are y'all to MRs? I want to port it to a few archs, but I'm not sure whether to hard fork or try to upstream.

We spent a ton of time trying to strike a balance in our CONTRIBUTING.md. Basically, we are happy to get PRs, but at the same time, we reserve the right to ignore them completely at the moment. We're trying to focus on shipping our product, and so are unlikely to be able to spend time shepherding PRs that aren't directly related to that. It's not you, it's us. For now. :) So yeah, we love to see the activity, and please give that a try if you'd like, but it's unlikely we'd merge new arches upstream at this point in time.

Word, makes sense. One of the major reasons why I'm interested in hubris in the first place is the strong opinion I have that systems code particularly should have a use case more important than "hey, look what I can do with this systems code". Lack of spoons on y'all's part kind of comes with that territory.

In addition to everything that steveklabnik said, it would be interesting to know which architectures you're eyeing, as some are much more modest (e.g., other Cortex-M parts/boards) than others (e.g., RISC-V). Things get gritty too with respect to I/O, where variances across different MCUs and boards can run the gamut from slight to dramatic. As steveklabnik points out, we are very much focused on our own products -- but also believe that Hubris will find many homes far beyond them, so we're trying to strike a balance...

I was eyeing RISC-V M/U-Mode with PMP. That's the closest thing to the semantics of Cortex-M from a memory protection perspective I can think of that's in common use still, plus I've got ESP-C3 and K210 dev boards laying around. I've been wanting to use them in my home automation, am cursed with the knowledge of what a nice RTOS feels like, and well, those yaks won't shave themselves.

Sounds like I should plan to do that on my own at the moment, but I'll keep it in a github style fork in case y'all's focus moves in that direction.

Check out Xous OS they are doing this kind of thing for RISC-V and want to use PMP.