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.
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>
It's crappy because it uses a busy wait loop to poll the udp
rx socket in order to accurately emulate the Xous async callback
feature (which is _not_ emulated for Tcp, for example).
It's more accurate because this emulation happens. But it's a lot
more complicated to implement it because zero-cost async UDP callbacks
aren't really a host-native feature (but they are a Xous-native feature!),
and I didn't want to .. pull in tokio or mio code surface into
the Xous hosted mode, seemed a bit like crushing a fly by dropping
a house on it. Maybe that's a fine solution in Oz, but Xous doesn't live in Oz.
Total bodge -- we lop off the TCP stack at the Xous API level, and
substitute it with a native host TCP stack.
Caveat hacker: this means that a lot of OS-specific net properties
will carry through to the hosted mode emulation. This is adequate
for "smoke testing" a build but do not be shocked, *shocked* if
there are more bugs to be found because of some weird host integration
issue.
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.
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.
Now that I understand how smoltcp does ping better I have regrets.
The demo example in smoltcp uses a funky macro that was a bit
misleading. I have gotten rid of that but I probably would have made
different decisions in implementing this had I understood the API better.
Anyways. It works, but has some trouble handling the cases of timeouts
sometimes.
