looks like about 9 crates will be affected by this. Point them
all to the latest version of the API, and specify the
"precursor" feature (which activates our patch)
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
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.
