Spent a couple hours chasing down a "bug" which is acutally just
something about how http works that I don't understand. TCP was
working just fine but there is ... idk some sort of keep alive
thing that occupies a socket so the "web server" blocks waiting
for a read. Anyways, I guess the "right" way to solve that would
be to make a multi-threaded web server
OH GOD STOP
right. it's just a demo to prove that TCP works. done.
Open an issue if you find a problem with TCP kthx!
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.
This moves the kernel into the main monorepo, allowing it to share
packages with the rest of the system. This change will allow us to
reduce the number of rebuilds that take place, as well as reducing disk
usage.
Note that the loader is still an indepenent project, and the integration
of that into the monorepo is pending.
Signed-off-by: Sean Cross <sean@xobs.io>
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.
So far it's been no problem to suspend these in any order, but as
more services come to rely upon them it's better if they suspend after
any client applications have been suspended.
resume failure was seen due to a crash in the engine-25519 process,
in particular, it's crashing on a try_send_message call.
Seems like probably the loader -> kernel transition could have
left some turds in the curve25519 engine, triggering an interrupt
when the system is not yet stable.
this attempts to smooth that over.
also add some bread crumbs on the more user-facing APIs to
help beginners out. Need to do a good spring cleaning of the
rustdoc tree, though. looks pretty terrible as it is.
we are at least now only requiring users to use our patched
curve25519-dalek crate, which now builds cleanly in both
xous and std environments, but the higher-level crates can be
directly used from crates.io
the engine-25519 server just takes microcode jobs and runs them
on the curve25519 accelerator engine.
all the fancy crypto stuff comes from other crates, which will
be filled in later.
