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.
fully integrates wifi on and off commands. measured standby power
when wifi is off is "immeasurable" (0 mA), so probably < 1-2mA.
fix ui transitions so that the off request is respected, through
sleep/resume cycles as well.
instead of sharing the wifi buffer loopback has its own buffer.
this eliminates a race condition that happens whenever an Rx
happens to happen on the wifi interface while there's loopback
traffic in progress.
also, i see a lot of opportunities to optimize the net stack now
that i have tweaked this path; it might be interesting to break
the receive interrupt out directly into the COM crate instead
of passing it through LLIO then NET then COM and having COM
drain the RX buffer immediately into a local "infinite" sized
queue.
The llio->net->com loop exists because the interrupt handler
for all the i/o is shared within one hardware block, but maybe
i can create an additional interrupt responder for the com
interface just to optimize things a bit in a future SOC update.
Alternatively, I could move all the interrupts into COM and not
have them resident in LLIO. This would optimize for COM latency
at the expence of I2C latency, but that's probably OK because
I2C is much less latency sensitive (i2c and com interrupt, as
mentioned above, share the same hardware block for external
pin-based interrupts).
- Peek now has a handler for reads that can't be met immediately
- add a count to the number of times a close socket has been polled,
if it exceeds a threshold close the socket anyways. This is a compromise
between trying to figure out how to implement a fully non-blocking TcpClose,
and having an interlocked one that cleans up state but ends up blocking
the case where you have, in the same thread, a sender and receiver
(which is ironically somehow legal and does not cause deadlock,
because the TcpClose in Unix is not blocking on internal state
being cleared up).
0 is a "valid" port and it means OS please give me a port.
This implements a method where a random port is chosen until
you find one that's not occupied.
If a Stream is opened and a process isn't constantly polling it,
it'll never close if the remote side goes away -- you'll just
end up hanging in a FIN-WAIT-2 condition.
Add some logic to detect this and close out streams automatically
where the remote has hung up.
I'm not actually sure this is what you're *supposed* to do, but,
lacking a formal specification, all I can do is try to get
this thing to pass the test bench. And pass it does.
TcpClose should not immediately remove the socket. It
has to wait until the FIN comes. Add a fin waiter state.
Also rewrite to use "retain". Woo. I'm starting to get
the hang of Rust closures. Only took a couple years.
RxWait gets stuck in CLOSE_WAIT state. It's a state where
you "could" transmit, but you can't receive anymore.
In this case respond with a 0-length receive? That seems
to be what leads to the right behavior. I would have thought
you'd want to respond with a timeout error but that doesn't
match what's in the test bench.
- add 127.0.0.1 to the list of IPs listened to by smoltcp
- add some static Atomic types to store the IP and MAC address
so we can process packets in other areas to detect the loopback
state
- add a routine to extract the loopback packets when they happen
- bunch of debug visibility tweaks
loopback packets are intercepted on the way to the COM and
re-injected directly into the Rx queue, along with a message
sent back to the main loop to pump the Rx buffer to extract the
loopback packet.
the CM can't always detect if the EC changes state; this is
especially true after an update or a forced reset where
the state caches are not reliably updated. If no packets are
seen for a while, poll the actual state and force a sync-up.
Also try to make sure that the interrupts are enabled correctly.
This macro will be removed, since it is no longer necessary. Remove this
macro across the project and replace it with a standard `main()`
function.
Signed-off-by: Sean Cross <sean@xobs.io>
smoltcp is written to allow multiple adapters, so 0.0.0.0 as
the binding for UDP is illegal. However, in Rust, it seems that
0.0.0.0 is "totally fine" and most OSes will resolve this to
a "default" adapter.
this patch introduces the behavior of taking 0.0.0.0 and mapping
it to a default adapter. In fact, we only allow binding to the
default adapter. The reasoning behind this is that if our IP
address changes, we would expect that 0.0.0.0 resolves to that.
Where this scheme fails is if someone binds to 127.0.0.1 expecting
it to not respond to packets coming in from the outside, e.g.
they are using UDP as a loopback interface. I think this isn't
a common use case for Xous, but if it does become one I suppose
we could add a code path to also check for the 127.0.0.1 case
and try to handle it...
smoltcp requires some polling to be done in the future for it
to work with low latency. It returns a time in the future for
the next poll.
This refactors the polling algorithm to:
1. use a fixed thread pool. This burns a little extra memory in
exchange for not having to allocate/de-allocate threads every
time a follow-up is needed.
2. use a short/long scheduler, where short delays (shorter than
the scheduler quantum) are grouped together, and only a single
follow-up is fired off within that time range if needed. Longer
delays have a larger window (roughly +/- 100ms) of grouping,
so fewer such events are also required in the distant future.
Empirically the delays seem to fall into two groups, either "short"
(less than 20ms) or "long" (around 700ms).
This improved scheduler uses fewer threads and generates less
messages, so instead of 16 threads and encountering exhaustion
we have 9 and have yet to see more than 7 used even under the
most strenuous tests (multiple while-true curl loops + fountain
test + ping simultaneously).
Some helpful debug is also printed now when scheduler runs out
of slots, so we can see the distribution of pending delays.
we no longer create a new interface on net reset, which means that
the socket handles don't blow up if we change IP addresses.
However, the ARP cache is still stale and there seems to be on way
to force it to flush....but I guess in theory, eventually it
should fix itself, if smoltcp is working correctly?
the refactor changes the way sockets are handled, so now, when
the interface is rebound we are certain to get panics.
working on resolving this detail now, but at least the interface
is working now and it seems more stable than before.
total threads in the net crate are around 10 right now, 32 max, so
increasing the sleeping thread limit to 16, since every now and then
we get exhaustion notes.
