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>
In general, hosted mode is assumed "by default" if the target
is not Xous. This allows packages to be built cleanly on command
lines that don't know to pass a --feature flag to specify a target.
However, an explicit "hosted" flag is still retained so that we
can confirm the build system intent. This saves us from the failure
mode that we thought we were building for target A, but accidentally
ommitted the flag, and instead we've been silently building for
"hosted" mode without any warning. The main consumer of the "hosted"
flag is now just the build.rs script inside of the utralib.
rkyv-derived enums throw warnings that they are unused.
Not sure how to get rid of them; I've tried surrounding them in
`#[allow(dead_code)]` directives, and also explicitly creating
each enum variant that I'm aware of through some dummy code and
some log prints of the dummy code calls to ensure the results are
used, and the warnings still persist.
Significantly, the warnings only happen for enums that take
a value. Simple rkyv enums do not throw a warning.
These warnings overwhelm the build logs, so they need to be isolated
in order for us to ensure that the build is clean of other more
important warnings.
The method chosen to isolate them is to take the enums that are
problematic, carve them into their own special file, and add
a file-wide `#![allow(dead_code)]` directive. This only happens
in 7 service crates, and this change commits all of the modifications
in a single big commit that could be undone later if this turns out
to be a compiler regression or something similar.
I also opened an issue with the rkyv maintainer to see what his
opinion is on the situation.
https://github.com/rkyv/rkyv/issues/318
This will allow for e.g. xous on riscv32-imac but not a precursor
target, for example: by using feature selectors we get to have
a bigger range of targets that we support, such as for implementations
that haven't been upstreamed or have official target-triples.
The downsides are:
- patch override libraries don't absorb feature flags. so, for
example, the AES crate that is used to patch other crates won't
be aware of the target features without modifying the referencing
crates.
- features are normally meant to be additive, but target features
are mutually exclusive. The mutex is enforced by a check in
utralib that throws a panic on build if two targets are accidentally
selected at the same time.
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).
