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
So there's a bit of a nasty bug that arises from the GAM
both handling drawing primitives and context swaps.
In particular, because the GAM handles both of these in a
single thread, context swaps can't block, because the redraws
triggered by the context swap would be blocked, causing a deadlock.
When the API token for the predictor was introduced, this added
a blocking operation inside the context swap. This would cause
a deadlock under certain conditions.
This patch refactors the API token so that it's not a return
result of swapping the predictors. Instead, the predictors
return the API token as a non-blocking message to the GAM. This
API token is correlated with the *GAM* token (not the app token).
Present me thanks past me for adding the GAM token, which was
as of yet unused, but now, there is a very sensible role for it--
exactly what it was made for, e.g. handling GAM-local API calls
without disclosing the application token.
Anyways, hopefully this patch puts the race condition to
rest, while allowing us to have per-context prediction histories.
The prediction API now takes an API token. This is a 128-bit
number that gets passed to the prediction engine, and it's meant
to be unique for every context that requires a predictor.
It's up to the prediction engine to do anything with the token.
For the "null" engines (such as the icontray for `vault` and
`tts`) the token is just ignored. But for example, in `shellchat`,
the API token is used to store a history record in a HashMap on
a per-token basis. This means that every app that uses the
`shellchat` history function gets their own history that can only
be read out by that app.
The actual token itself is mostly passed through the API. The
token storage is in the Context layer (each Context has a record
for a token, that starts as `None`), and is passed down to
the predictor every time the context swaps, and the predictor
receives the token and passes it back if the token was `Some`,
or allocates a new random token if it was `None`.
Note that everything is a Context, including, for example, menus and
modal dialog boxes, but not all contexts have predictors. Only
Contexts that ask for a predictor have them. This mechanism
works smoothly in this model (as opposed to other hacks and work-arounds
previously tried getting to this solution).
in "menu mode" the predictive area functions as four menu
option keys instead of dynamic prediction updates.
this patch is mostly working but we need to figure out how to
force a redraw of the predction area when the app is raised,
because we get a stale image from the previous app on context
switch.
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.
