Was doing disjoint loads and stores on an Atomic, really, should
be using the fetch_add, fetch_sub variants to be proper.
Didn't seem to impact anything but maybe there's a future version
of me that high fives me for doing this.
the re-regsitration is a "send" not a "lend" now, because
the imef can't block during the context switch.
Not sure why I made it a lend in the first place, probably just
wasn't thinking...
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.
the connection number is re-used for all objects created
within a process space, so you can't `Drop` the connection
immediately when an object goes out of scope. You have to
make sure all instance of the object go out of scope. This
patch adds reference counting to all the objects so that
the `Drop` function works as intended.
This rewrites the entire project so that most runnable projects now use
`xous-ipc` instead of `xous::String` where possible.
This also removes `rkyv` from the list of dependencies in `xous-rs`.
Signed-off-by: Sean Cross <sean@xobs.io>
xous server names are 64 characters long, not 256.
maybe should refactor to just eliminate the xous server name
structure -- it's actually redundant, and a vestige from when
we were just figuring out how to use rkyv.
rkyv does some optimization to not send all the data in
a string if you don't use it up.
xous assumes the same "pos" argument on the return type
thus a variable length string doesn't work as a return type
(you can send it, because you can specify a "pos" on the send
side).
fortunately, the application for the variable-length string
was getting predictions out of the predictor, and a short (31 element)
fixed-length array with a side companion of a len variable
should be more than sufficient for completion suggestions.
probably should be the *only* implementation because these are
only concerned with IPC calls that really require changes in
two separate crates, but I feel unconfident enough about the API
that for now I want the flexibility to experiment with non-default
APIs until I'm ready to freeze things.
