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.
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.
