The rationale is that xous-rs should have only architecture
specific code, e.g.: riscv, arm, x86, etc. To make other
crates that depend on it not specify the features.
This could be useful when using xous-rs with `libstd`
for example.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
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.
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.
