verification is sort of pointless, because:
The Cargo.toml file is parsed and reformatted by the packaging tool to normalize its contents.
Thus, the Cargo.toml file of the downloaded version never matches the Cargo.toml file that's actually used.
Unfortunately, there doesn't seem to be an easy way to check the equivalence of two Cargo.toml files,
except for recursively and deeply parsing through and comparing all the possibile keys and values of
the abstract key/value tree. This is a much bigger project than I'm prepared to figure out today.
As a hack, we compare to the Cargo.toml.orig file. Which is...kind of OK, but really, this opens us
up to attacks where someone just has to replace a version on a package or even just swap out an
entire package for a malicious one by just using package name re-assignment which is a thing that
the format supports. In other words, all this checking is kind of pointless because it's super-easy
to swap out key crates for whole other crates and have it go undetected.
- strip out gdb-stub. Per xobs, the feature never worked, and it
depends upon a branch of a git repo which is not allowed by crates.io
Since the feature hasn't been developed, and crates.io will not
allow even an optional feature that points to a git repo, the feature
was stripped out.
- rename "kernel" to "xous-kernel", so that we can live in a crates.io
package namespace that is specific to Xous.
still have to figure out the riscv package issue.
this is necessary because we need the full SVD path to generate
the whitelist of physical pages that can be addressed. Since the
SVD path is now domiciled in utralib, a file called "SVD_PATH"
is created in the target/ directory which contains the resolved
path to the SVD file given the abstract target/rev feature pair.
this fix makes it so that
1) you always get a correct build when the SVD spec is toggled
2) you don't always rebuild when nothing has changed
(2) is with the caveat that the no-change flag is only clean
after your second build (i.e. your third run will be fast).
I'm not quite sure why but I think it's because the "changes"
to the config file tracker are computed throughout the first
build and the second build still sees that file as recently
changed, so, it'll trigger a rebuild (could also just be
a race condition because the timestamp of the rebuild is
at the same second that the file was regenerated, so conservatively
you'd rebuild the next time).
- default SVD file is specified now as a constant at the top of xtask
- SVD files are now tracked to commit refs in the betrused-soc tree
this is so that we don't have to guess which crate rev corresponds
to which SVD rev -- we specify it explicitly with a feature flag.
also add a routine to manually switch over the UTRA in this case.
for whatever reason, the system is not picking up the change in
the UTRA when specified as an environment variable change --
maybe there is a hard coded link somewhere, but I can't seem
to find it.
since performnace counting is an edge case use mostly by
frankly just me, I'm not going to worry about ergonomics so
much.
turns out, they're pretty useless. I mean, for debugging actual
running code. it tells us basically what we know already which is
99.99% of the time is spent waiting on inter-thread messaging
in hosted mode.
adding a key of "submenu" will automatically create the corresponding
integer argument of submenu contexts for the app.
NB: you should try to only create 1 and re-use it. Menus
are resource hungry, and will rapidly eat through your connection
and thread table.
