This call can be used by clients to try connecting to a service. If the
service is not available, this will fail to connect.
Signed-off-by: Sean Cross <sean@xobs.io>
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.
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.
Mangement tokens were added to xous-names for the special case of
servers that had exactly 1 connection, so they could explicitly
control when they are disconnected (preventing e.g. griefing by
rogue processes).
This was a good idea except it also conflicts with the "eager TOFU"
model of Xous security when you have servers that act as plugins to
each other. Eager TOFU means Xous has a "trust on first use" model
for capabilities, and eager implies that anyone who will use
anything will claim it early on. This gives the important property
that one can ask, "has everyone eaten their TOFU?" before doing
anything really sensitive. If all the TOFU slots are used, then
you can conclude that no new rogue servers can inject themselves
into sensitive APIs and you can move forward.
In the case of a plugin API with multiple plug options, when
you unplug something, the previously eagerly occupied slot
now becomes unoccopied -- and this becomes a flag against
the TOFU check, disallowing sensitive operations to proceed.
This is *particularly* a problem with the predictive history
plugins for the IME. The architecture was created to allow
for multiple histories to be used. Up until now, only the shellchat
plugin was ever used, so, the eager TOFU check always passed.
However, in creating more applications, this flaw was uncovered
once we introduced a second plugin.
This means predictors can not delegate their security to Xous-names.
They must individually implement API tokens to control access
to the prediction history (to prevent rogue apps from e.g. connecting
to the predictor and then reading out the prediction history to
figure out what the most recent words were typed).
A subsequent commit will add the API tokens, but this commit simply
has xous-names return a mangament token even if servers with
more than 1 connection are created. The main downside of doing
this is the management token lose meaning in the context of
multiple servers; but, so long as the tokens aren't used for
anything in those situations, it's fine (cue burning building
meme).
More importantly, it allows the existing code to manage the xous-names
count to function even on a server that sets no explicit limit
on connection count, which is now going to be the case for the
prediction engines going forward.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
This opcode allows a client to request a connection to the Server, and
will only return if there's an Error or a Connection.
This contains future support for AuthenticationRequests, however those
are not yet implemented.
Signed-off-by: Sean Cross <sean@xobs.io>
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.
