Add support for libstd calls to pddb.
The pddb uses `:` as the path separator, and grafts the concept of paths
onto dicts.
Currently implemented features:
* mkdir
* rmdir
* create file
* open file
* read file
* write file
* unlink file
* seek file
Other calls may be added as needed.
Signed-off-by: Sean Cross <sean@xobs.io>
the sizing was such that two pages of data had to be prepared
for even very short messages. This change fits the message back
into one page of data once again.
The `ManagedMem` thing for the suspend/resume crate is simply
a disaster. It tries to be fancy and Rusty and really it just fails
in non-obvious ways. This is one of the places where it simply
does not pay to make things seem so simple.
Why? because in reality, memory is complicated. It comes in pages.
There's initialization. There's caching. There's volatility.
I haven't encountered a single situation where the assumptions
of page-alignment and memory layout have really lined up well enough
for this primitive to make sense. The "idea" was hey, since
you allocate a peripheral MemoryRegion, why not just use its attributes
as a marker to a suspend/resume thing that automatically handled
stashing that MemoryRegion to a backing store inside RAM? Seems
simple right? wrong. Every time I've tried to use it, it's failed
in non-obvious ways.
In this most recent incarnation, it turns out that for whatever
reason, it seems to be just stashing about the first 4-8k of the
framebuffer to the SR backup region, and then somehow grabbing
a future(?) copy of the memory? or maybe just a wrong copy? I don't
know. The code seems simple enough but it goes through some
traits and some type transformations and then there's some unsafe
code to make it volatile and it doesn't work.
Instead, we just use a damn [u32; FB_SIZE] slice to store the
frame buffer. This is so obvious and easy. The only price is
you have an "ugly" `fb[..FB_SIZE].copy_from_slice(&self.srfb)`
line instead of an "elegant" `srfb.suspend()` invocation.
Stashing into it is a bit uglier, because we have to cast the
slice to an unsafe pointer in order to access the `write_volatile()`
method. But, it works! It. Just. Works. And you can see what's going
on. Really, I should stop trying to be fancy and just be readable.
OK anyways, that was that rant. This commit also adds some
calls that allow us to re-use the suspend/resume frame buffer during
"normal" times as a stash/pop for the application image. This is
nice because the memory is normally idle/overhead when not
in suspend, so now we're repurposing some already-allocated memory
to accelerate some drawing operations, and it also makes, crucially,
a multi-step blocking modal dialog interaction less cosmetically
jarring, because the application thread can be fully blocked and
not responding to redraw commands but the stash/pop mechanism
creates the illusion of "everything is moving along".
1. add foreground/background tracking, such that if we return
to a context instead of redrawing it, we stash the framebuffer and
restore it.
2. make foreground/background context swap messages mandatory
previously, we were "light fingered" about sending the message --
we'd only send them to apps. the app was not considered to be
"backgrounded" if a menu came up in front of it.
This turns out to be a mistake. Now, we background apps when
a menu or dialog comes in front of it, and then foreground it when
the app goes away.
- fix problem where we were generating a size based off of total disk
size, instead of fraction of available space
- enumerate FSCB entries into the page table scan. This is because
the page table cache could hold used entries that aren't reflected
in the low-level disk scan, and there is no way to trigger a
flush at the point of re-allocation.
- add an autotrigger feature for the basis stress test so it can
be run in a fuzzer loop
- various fixes and improvements to the implementation to help
integrate with CI
this commits a script that will repeatedly rerun the `btest`
which creates several Bases, fills them with pseudorandom datat,
and goes through a lock/unlock cycle.
should be run with the disk size set to 4MiB for maximum stress
testing (the larger disk won't trigger an FSCB refill because its
hard to run out free space on the larger disk size)
The ServerID return type was placed in the middle of the results list,
which caused results 8-15 to be shifted by one to become results 9-15,
with result 8 being swapped with result 15.
This fixes this offset.
Signed-off-by: Sean Cross <sean@xobs.io>
When the "autobasis" feature is selected, the hardware block
will track all basis that have been opened and unlock them when
it comes time to scan/generate more FSCB space. It also bypasses
all UX normally invoked.
This allows us to create tests that open and close Bases automatically,
but of course, totally destroys the notion of plausible deniability.
So, don't turn the feature on for production.
As the REPL format comes from
[Renode Platform](https://github.com /renode/renode),
I believe the word 'Rebide' to be a typo for 'Renode'
(given the proximity of the letters on a keyboard).
Let's hope it'll make this tool more prominent in search results.
Signed-off-by: Ludovic LANGE <llange@users.noreply.github.com>
need to cover the case that no enumeration was done, and just
show a "null" list confirming basically nothing other than
the system basis is disclosed.
