0.5.1 rand_core needed for the dalek crates
0.6.3 traits everywhere else
what a mess
turns out i can just use fill_via_next() to do the same thing
without having to step on cross-generation traits. whew.
(also not in tree but doing a quick manual test that fill_via_next()
is not totally broken)
Code now builds, but, it doesn't fully work. Also,
the vault backup vendor routines have yet to be wedged in.
On the other hand, this edit is much more targeted than
the first one, so hopefully future port-ins of OpenSK
will be much smoother. In particular, OpenSK has a nice
`env` abstraction that has enough power now for us to
stick most of the Xous-specific stuff in there. There's
still a few patches needed to the main code loop, mainly
to accommodate our ability to display more information
than flash an LED.
The storage layer is also migrated to a totally new
dictionary, because the latest version also completely
redoes the storage with some sort of key/value system,
which maps nicely into the PDDB.
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.
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.
Woo? we have CBC encryption using Rust's most favored AES library
now.
I have a feeling I'm going to be re-doing all of this once they
decide to finally take GenericArray out back and shoot it....
*everoyne* is relying on rand_core, a later version, that uses
a "getrandom" thing that tries to make the call for random
number generators generic.
I mean, it's kind of cool, but, it's also sort of a libc
non-pure-rust nightmare because basically it always delegates
to a C-style API for a variety of platforms.
Next step is to see if we can't...patch...getrandom to point
to a much simplified, xous-only version that is 100% pure Rust.
