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.
- you can only "patch" regions of memory. caller provides a slice
to the region of data they are patching, so that patches can be
computed by the lib-side code of the server.
- erasing is done with a "patch" with all 0xff's as the write data.
a sequence of pure 0xff for a page does not actually cause a write,
the condition is detected and the write is skipped after an erase.
- patches attempt to be somewhat intelligent and not re-write unchnaged
data, or erase blocks that don't need udpating. However, if a user
submits a "sparse patch" with just a couple bytes modified in a
megabyte region they can expect bad performance. Ideally, in that
scenario, each of the smaller modifications are submitted as
individual calls to the patch function, instead of regurgitating
all the data and hoping that hthe patch function does some intelligent
diffing to be as light-fingered as possible about updating the flash.
In other words, the onus is on the calling server to format
patches intelligently. The patch server does only the simplest,
safest optimizations. You don't want to be shuttling megabytes of
redundant data anyways between servers for many other reasons....!
