search

oxidecomputer / hubris

A lightweight, memory-protected, message-passing kernel for deeply embedded systems.
Mozilla Public License 2.0
3.01k stars 173 forks source link

Current policy on upstreaming chip support? #490

Open faithanalog opened 2 years ago

faithanalog commented 2 years ago

What are your thoughts on merging in additional chip support into this repo at the moment? I have some interest in improving my nRF52832 support, or bringing up support for some of the other boards I have lying around my apartment as I figure out which ones have the necessary hardware for it. I'd be happy to pull request those, but I don't have a full picture on how much overhead (if any) that would impose on your dev workflows, and I guess it could create the image that they're "officially supported" if they're merged in here.

My other idea is to maintain a fork with unofficial chip/board support, in the spirit of "This is some unofficial hubris-compatible stuff, also don't expect me to track upstream at full speed I'm just one girl with a rust compiler".

steveklabnik commented 2 years ago

Speaking purely for myself: yeah, we don't have a very clear written policy here. In general, it feels to me like:

  1. In general, we're really happy to see Hubris ported to more stuff
  2. Having things in this repo that we're not actively using does put a drag on things; for example, if CI breaks, that'd be bad. But also not testing support would be bad.
  3. Sometimes, things get a bit fuzzy. It really depends on the details.

To see previous discussion on this, for example, https://github.com/oxidecomputer/hubris/discussions/365 is about RISC-V support, which is something we originally thought we were going to do ourselves, decided not to, but someone built, and we're still kinda talking about if/how to integrate it. https://github.com/oxidecomputer/hubris/issues/454#issuecomment-1069558308 is related. https://github.com/oxidecomputer/hubris/discussions/357 is also a kind of related discussion.

So yeah, sorry that's sort of a non-answer, but hopefully gives some amount of context.

My other idea is to maintain a fork with unofficial chip/board support, in the spirit of "This is some unofficial hubris-compatible stuff, also don't expect me to track upstream at full speed I'm just one girl with a rust compiler".

This is also 100% okay, of course. I also recognize that "keep your own fork" isn't as nice as having stuff upstream.

moosingin3space commented 2 years ago

Perhaps a fork named something like hubris-community that holds support for community-maintained chips is an ideal solution here. I'm currently doing an exercise where I try to bring up Hubris on the RP2040, and it would be nice to have a place for it to end up.

mchodzikiewicz commented 2 years ago

I think it would be much better to split the repo to have separate core (kernel + build system) and some topic related sets of chip configs, drivers and tasks and finally keep the final apps and demos as separate repos - this would allow community to extend the feature set of Hubris leaving the responsibility for keeping up to dateon a community member that maintains a subset.

Since Hubris is not that friendly for amateur makers, I guess the great target for adoption beside Oxide would be high reliability systems (especially combined with upcoming Ferrocene), but then it is hard to advocate bringing Hubris into such projects with piles of code that'll end up unused since you need to formally prove quality of every component in scope.