search

oxidecomputer / hubris

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

userlib: remove panics in kipc implementation #1937

Closed cbiffle closed 1 week ago

cbiffle commented 1 week ago

The kipc stubs tend to assert on the rc value received from the kernel. This isn't ideal: we generally have to trust the kernel, and we can't do anything useful if it misbehaves. So the assert is merely costing a bunch of flash for a condition that can never happen. This removes these asserts.

The system_restart kipc needs to indicate a "noreturn" send, but of course we have no way of doing that right now. So, it panicked if the send returned. This created another can't-happen panic site in flash. I've replaced it with an infinite loop that compiles to a two-byte branch instruction, and in practice will never even be reached (but the compiler doesn't know that).

This further reduces text and stack size in El Jefe.

cbiffle commented 1 week ago

Out of curiosity: can Jefe stack size allocations reasonably be disembiggened in any of our app.tomls now?

@hawkw probably, but the process of finding them and right-sizing them is unpleasant and I'm currently not up for it.

hawkw commented 1 week ago

Out of curiosity: can Jefe stack size allocations reasonably be disembiggened in any of our app.tomls now?

@hawkw probably, but the process of finding them and right-sizing them is unpleasant and I'm currently not up for it.

That's entirely reasonable; I wasn't going to say you had to do it now, or anything. And, I think it can be justified by saying that, in the absence of better automated processes for estimating max stack depths, giving the supervisor a bigger stack margin is probably more useful unless we are actively trying to scrounge up a few more bytes of RAM for some specific purpose, which we're not at present!

cbiffle commented 1 week ago

@hawkw if you like getting stack back, you're going to love my next PR. ;-)