a lot of re-import warnings have cropped up. While I appreciate
their studiousness on this, the problem is that removing some
of these exports in the API crate could mean that future users
who want access to some API features that aren't used in this
configuration are now unaccessible.
I think it's not a huge problem at the moment, just spam-cleaning
the warnings because there are too many to deal with carefully
at the moment.
unwrap on a routine always returns None, so the unwrap() has no meaning
(probably originally introduced just as a way to get match arms to
have the same return result without thinking too much about it).
panics happen due to certain default states of the EC
wire protocol, due to a MAC address being passed in that is
not unicast when garbage data is present.
Mark `MemoryRange::as_slice()` and `MemoryRange::as_slice_mut()` as
unsafe.
This is due to the fact that not all representable types can be cast to
an arbitrary value. For example, if Process A sends random values to
Process B, then Process B casts the memory to a slice of `bool`, then
any values that are not 0 or 1 are undefined.
Because these functions can leak UB into the program, they are marked as
unsafe.
This patch adds `unsafe {}` blocks to all instances where this function
is called. Additionally, all instances have been checked to verify that
they do not cast to any invalid types -- most use `u8` or `u32`.
Additionally, the long-deprecated `MemoryRange::from_parts()` call was
removed, since that causes UB without being marked as unsafe.
Signed-off-by: Sean Cross <sean@xobs.io>
ssid scans can now be in-progress, and they also record
the time elapsed since the last scan was performed.
this allows the network manager to be a bit smarter about when
it decides to kick off a scan.
the ssid scan dialog box is also updated to show
the scan results in progress. This addresses #336.
The crate just re-exports the com_rs crate. This patch changes usages of
com_rs-ref to use com_rs directly.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
In general, hosted mode is assumed "by default" if the target
is not Xous. This allows packages to be built cleanly on command
lines that don't know to pass a --feature flag to specify a target.
However, an explicit "hosted" flag is still retained so that we
can confirm the build system intent. This saves us from the failure
mode that we thought we were building for target A, but accidentally
ommitted the flag, and instead we've been silently building for
"hosted" mode without any warning. The main consumer of the "hosted"
flag is now just the build.rs script inside of the utralib.
rkyv-derived enums throw warnings that they are unused.
Not sure how to get rid of them; I've tried surrounding them in
`#[allow(dead_code)]` directives, and also explicitly creating
each enum variant that I'm aware of through some dummy code and
some log prints of the dummy code calls to ensure the results are
used, and the warnings still persist.
Significantly, the warnings only happen for enums that take
a value. Simple rkyv enums do not throw a warning.
These warnings overwhelm the build logs, so they need to be isolated
in order for us to ensure that the build is clean of other more
important warnings.
The method chosen to isolate them is to take the enums that are
problematic, carve them into their own special file, and add
a file-wide `#![allow(dead_code)]` directive. This only happens
in 7 service crates, and this change commits all of the modifications
in a single big commit that could be undone later if this turns out
to be a compiler regression or something similar.
I also opened an issue with the rkyv maintainer to see what his
opinion is on the situation.
https://github.com/rkyv/rkyv/issues/318
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.
