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.
suspect maybe the custom vex routine for cache flush has a subtle
issue, so fall back to first-principles read-region flush.
remove excess calls to flushing as well, turns out we effectively
duplicated the call because it was both in the core patch routine
and outside of it too.
When ditherpunk flag is enabled, graphics-server cannot start.
I suspect macOS doesn't tranfer thread-local variables when a new one
is spawned, and this makes xous-names, logs crash.
This commit adds a compile setting that will bypass ditherpunk thread
settings on macOS as well, allowing developers who happen to run this OS
to develop and prototype for betrusted again.
the llio power-cut mechanism is no longer effective with
the power-down sequencing required by susres. use the susres
mechanism instead, and depracate the previous method.
The implementation is a bit clumsy because the original
premise of the login loop is that it should be infalliable, and
because of the isolation of the password mechanism there isn't
a great way to pass number of failures back and forth across
that firewall (and I don't think there should be).
The application calling the password routine tracks failures
but the mounting routine has to kick that up to the main loop.
However, the PDDB main loop can't get stuck on the mount attempt
if you want to suspend, because it has to respond to the suspend
request.
So the failure message has to get kicked all the way back to the
status thread, which is what kicks off the mount, and then handled
there.
