Don't send FocusState::Foreground / FocusState::Background messages
to Layouts that are non-App type. This allows this to be used more
reliably as a signal of if the background is the running app or not,
rather than if it is merely the drawable canvas.
This doesn't work because the shutdown call destroys all the servers then terminates
the processes. But, the problem is that the processes are still
running, but servers are disappearing. So what you end up with is a
panic when the first message gets delivered to a server that no longer
exists, and then you end up with the program hanging on that panic
because some servers haven't been destroyed/exited yet and are now
just spinning waiting to be scheduled. so the call works in the tidy
kernel test cases but to get it to work on a full OS you'd need to
have a way to put every server into an eternal blocking state before
making the shutdown call (to prevent new messages from being issued
while servers are going away), which is more work than i'm willing to
put into the problem right now.
now that the suspender is in its own thread, we can do this safely.
It's nice to have a bit of a delay because we want other system recovery
things to take precedence and settle out before we try pinging the COM
to see how the wifi changed while we were asleep.
Add a "Later" stage, and have exactly one "Last" stage.
"Last" to suspend is the ticktimer -- this is crucial for
basically everything else to work. The other really
low level stuff that needs to work to the last minute is
now in the "Later" bin.
the connection manager actually wants a ping on resume,
and when we suspend we suspend -- "it is what it is". However,
the connection manager is a hairball that can block for a while,
so, to prevent failures to suspend, we put the suspend listener
in its own thread, and on resume the suspend listener will
automagically kick out an event to tell the connection manager
to deal with stuff.
This call was originally part of the RTC driver, but when we
refactored things out, this was forgotten.
So, what would happen is, if you did a coldboot or reboot,
an alarm would get set and...well, the way the RTC blocks
is it'll keep asserting the alarm until you clear it.
This prevents the system from sleeping, and also keeps
the CPU pegged at 100% for some reason. The prevention
from sleeping makes sense to me. The CPU at 100% probably
indicates there's a problem in the event router, but
this path isn't used for anything at the moment so
we'll just open an issue and leave it as technical debt.
An edge case was missed where a page which was allocated out of
the FSCB and then later written to disk was having its journal
number set to 0.
The root cause of the logic issue is that the page table itself
does not store a journal number. It's assumed that the page table
is ground truth, and is unjournaled.
As long as the pages don't exist in the FSCB, that's not a problem,
the journal number doesn't matter.
But, let's say this sequence happens:
1. FSCB allocates some free space
2. process takes that free space allocation and commits it to its own page table
3. FSCB update log gets a note that free space is now allocated
4. system reboots
5. process reads its page table from disk. There are no journals associated
with the page table on disk, so, it assigns a journal number of 0 by default.
6. we now have a conflict between the Process' view of the journal age
of that page table entry, and the FSCB's view.
The fix to this is during the page table scan, to check and see if
any candidate pages happen to already exist inside the FSCB. If it does,
then you adopt the latest journal number for that page in the FSCB.
This keeps the two views consistent.
A second bug was also identified while fixing this where the "Random"
order we were hoping for in visiting the free space cache as an
iterator is less random than we had hoped. So, there is a patch to
extract the free pages and pull one random one from the pool, using
entropy coming from the TRNG. This is less computationally efficient,
but at least it is correct and has more transparent properties
than relying on the indeterminism of the HashSet implementation.
- add a "dangerous debug" command that only exists when the feature
"pddbtest" is enabled. The feature can't work on real hardware, but
still, it enables things like dumping of the database and storing
the keys for inspection, so it's isolated in a feature that prevents
the code from being compiled in the first place when it's not selected.
- fix a bug where keys that have zero length aren't being created
correctly. this is a common use case for reserving some space for
data that isn't yet available.
previously blitstr2 is using usize for x/y coords, which means that
for layout purposes points could not go to the top or left boundary
without causing arithmetic overflow. Of course, you want to render
everything on-screen, but, as we have multi-line text with overflow
possibility, it's reasonable to be able to use negative coordinates
to locate text boxes that flow into the visible region.
This of course means that occassionally you can come out with
things like "negative widths", but even then, there can be reasonable
uses for this as an intermediate in calculations that ultimately
arrive at a positive result.
modals don't work when triggered in the status thread in hosted
mode (but they do, somehow, on real hardware). I think this
is an actual locking problem that would exhibit itself if
we had a true multiprocessor system, but since real hardware
is a single processor it doesn't show.
