The approach here turns the usb-device crate "inside out". The
working hypothesis for the unreliability of the previous implementation
is that we try to do all the IRQ-handling in userspace, where
the operation can be pre-empted. Unfortunately, this doesn't set well
with the corigine USB hardware driver, as it assumes that it has
the full CPU attention while its state is being manipulated (and
some things must be responded to in basically real time otherwise
you get protocol inconsistencies).
In this implementation, we use the Xous subsystem to do the
API-level exchanges of information to a USB handler that, for the
most part, runs directly inside an IRQ context.
There's some trickiness in terms of sharing the hardware state
across the boundary between IRQ and userland, but most of it
got handled I think fairly cleanly in this implemnetation by
using the xous-native server queuing mechanism to shuttle data
in between the two domains. The main spot where I think panics
can creep in is in data transmission, where the Tx data is
shoved into a RefCell and then the IRQ is invoked to pull the
data from a RefCell. As long as we don't invoke the IRQ to
pull data from the RefCell while it's borrowed mutably, we should
be OK.
Wrapping the structure in a Mutex actually doesn't help here
because the IRQ context can't do a "wait" to get a lock - it
would never get it, because it's in an uninterruptable context.
Thus we skip the complexity of a Mutex and let Rust panic if
we mesesd up the data hand-off.
there's now unfortunately branch divergence in the NTO/MPW
code base
The methodology is to code like we're running on NTO, and
if the "mpw" feature is selected, we put hacks in to run
on MPW hardware.
Under the theory that MPW should be totally deprecated
once NTO comes out, and therefore the hacks should accumulate
in the MPW code base (and ideally be somewhat easy to cull when
the time comes).
this is probably the most significant source of consternation but
also this code path has been fairly well-trodden.
That being said it might be worth considering if there is any
way to use some of the new Rust const based reasoning logic
to see if we can't tighten this up someday, but today is not
that day.
So in Rust 1.83, we now get a strongly worded warning telling
us to really, really don't use static muts. They aren't wrong,
except that in some places like the kernel we have few options:
we are conjuring pointers out of thin air, creating memory mappings,
and then doing things with them that are hard for the compiler
to reason about.
I think the newly minted warning was made because the intention
is that we could use the new fancy `const` semantics to take
the place of static mut usage by wrapping things in UnsafeCell,
and I think maaaaybe in some
cases this could apply here, but as a simple example a dive
into the kernel debug UART indicates that to initialize the
shared variable we have to allocate pages in the page table,
which involves calling the memory manager and doing some
decidedly non-const type of things. So one option is we could
just push the debug UART initialization into the loader and
paper over the whole thing by pretending it's static.
Instead of that, we adopt a pattern of casting all our static
muts to a raw pointer, and then back into what we want. The
cast to raw pointer is like an "uber unsafe" marker that says
"no we really mean that this pointer is where it is and we
conjured it out of thin air and we promise that the behavior
is defined and values are representable, etc.".
In general we're fairly judicious about the use of static
mut in the kernel, and when in the kernel there's no thread
pre-emption (although we could take an interrupt or page
fault) so generally we are single-threaded. The trickiest
spots are when we have to take a page fault while handling
a page fault (for example, allocating a new L1 page table
entry would require something like this) but this code path
is fairly carefully vetted.
So instead of just doing a global lint silence, we use an
`&raw` idiom to call out the fact that we're doing something
naughty wherever we do it, which makes the compiler "happy"
(for now) while still making the code ugly enough that it
looks sufficiently scary and you have to apply some
cognitive burden to even reason about what's going on,
which I *think* is the intention of Rust in this case.
Basically you get a get out of jail free card but you can't
simply wear it on a lanyard and pass through the gate -- every
time we need to use it, we have to do a little dance and
wash ourselves in the waters of unsafety and recite the
mantras about defined behavior, representable numbers, thread
safety, etc.
