I was this many years old when I learned that:
- If you put a `let` inside a block and then pass it outside
the block, it definitely gets a different address. This was causing
KP's in the interrupt handler routine because I was using a block
to mark off the configuration feature and then passing the handle
to the data structure outside the block; instead of just aliasing
the handle over as I assumed it actually makes a copy in a new
address location. This made debugging really hard until I figured
that out, the solution was to put #cfg directives on every line
related to the feature instead of grouping them together into a
block and using a single #cfg directive.
- event_wait() takes longer than 2us to execute. However, the
sha512 computation is done in 2us. So, by the time we checked
if we should wait and called event_wait(), the interrupt that
would wake us up from event_wait would have already happened.
This race condition is what broke event_wait() in the first place.
We now just use a spin loop without even a yield(); as the yield
would take longer to execute than waiting for the hash function
to finalize.
When the hardware engine is unavailable, the implementation
falls back to a software SHA. This code path is actually
rarely used, but it is the top object code consumer according
to our bloat analysis tool (40kiB for each instance of
the compress function alone).
This patch annotates the SHA functions with `#[inline(never)]`
to reduce the size of these rarely-used functions.
...it might actually be that on our small-cache system,
reducing the in-lining could improve performance as well
because it helps the whole routine fit inside L2 cache.
Anyways, it's a rarely-used path (I've never seen the code
used once tbh) so let's reduce its overhead and keep
Xous trim.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
Each Cargo.toml now includes a comment which remnids maintainers
of the dependency policy for Xous (that is, nail down every dependency
to the minor number).
Versions are pinned down to the minor number. Yes, this means that
we don't automatically pull in features and bug updates from crates.io,
but it also means we don't pull in new attack surfaces and code that
hasn't been tested or reviewed. I'd like this process to be very deliberate
and not automatic for Xous.
The `rand` crate is almost pinned down to a single version, except
for an odd dependency that's pulled in by hosted mode that depends
on rand 0.8.4 via a subordinate dependency via the `tempfile` crate.
Pondering if it's worth it to try and eliminate that, because the
0.8.4 version doesn't get compiled into any version that touches
real hardware. It just makes it harder to analyze the Cargo.lock
file, mostly. I think I'll leave it as-is.
So far it's been no problem to suspend these in any order, but as
more services come to rely upon them it's better if they suspend after
any client applications have been suspended.
this prevents less trusted processes from connecting to servers
after the kernel initializations are done.
this works so long as we don't have disconnects from the kernel
servers. In order to support disconnects we will also need a
way to re-enumerate the SID to guarantee that we don't have a re-use
problem. But for now, the kernel is not designed with any practical
disconnect mechanism; there is no code that calls the Quit mechanism
on any server.
