Enable a panic-free Jefe for the first time

[cbiffle]

The supervisor task in Hubris is not permitted to panic, since it's responsible for handling panics.

Jefe has historically contained a bunch of (static) panics, many of which aren't actually possible at runtime. I've been gradually grinding away at these in my other PRs.

As of #1937, it's now possible to build a minimal Jefe (like we use on the G0) that contains no panics. So I've enabled that on donglet, and turned on the userlib/no-panic feature that will statically ensure it remains true.

Turning on dump support in Jefe causes a bunch of panics to reappear, because humpty is panic-heavy. That's a task for another day.

[hawkw]

[hawkw]

Hm, what are you imagining here? A newtype representing a validated task index that's in range? IIUC that would also mean having a newtype around a task states array in kipc that has a safe unchecked index operation taking that type, right? And at that point it feels like stuffing a lot of Jefe into the kipc crate...

Or, am I misunderstanding the idea?

[cbiffle]

I was thinking maybe a wrapper for find_faulted_task that also takes an array array and indexes it for you, based on this validity assumption. So it'd be like

fn find_faulted_task_plusplus<T>(start: usize, array: &mut [T; NUM_TASKS]) -> Option<(NonZeroUsize, &mut T)>

And at that point it feels like stuffing a lot of Jefe into the kipc crate...

You're not wrong about that, but since kipc is mostly intended for the use of the supervisor... if we find a genuinely repeating pattern, moving it into the crate isn't necessarily bad.

This one might be too special purpose though, which is why I left a TODO instead of attempting to design it.

[hawkw]

I was thinking maybe a wrapper for find_faulted_task that also takes an array array and indexes it for you, based on this validity assumption.

Oh, that's much simpler than the API I had envisioned, that seems like a good idea!

And at that point it feels like stuffing a lot of Jefe into the kipc crate...

You're not wrong about that, but since kipc is mostly intended for the use of the supervisor... if we find a genuinely repeating pattern, moving it into the crate isn't necessarily bad.

Yeah, I think it's entirely reasonable for kipc to have APIs that might be reasonably used by any supervisor implementation, which I think a find_faulted_task_in_array (or whatever you want to call it) would be. I guess it does kind of make the assumption that a supervisor implementation will want to store per-task states in an array, but I don't know why you wouldn't want to do that, and you can just not use the API if you're doing something weird...

[hawkw]

take it or leave it: perhaps we ought to add something like:

#[cfg(all(feature = "dump", feature = "no-panic"))]
compile_error!(
      "the \"dump\" feature cannot currently be enabled when \
      \"no-panic\" is enabled,
");

at the top of main.rs?

i realize that enabling them both will get a linker error anyway when humpty tries to link with the panic impl, but it might be nicer to actually tell the person who enabled both features the specific reason Jefe is trying to panic, rather than making them go and figure it out? not a huge deal though.