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>
Instead of having a single, shared buffer, simply stack-allocate the log
buffers.
This paves the way in the future to allow for buffers that are
larger-sized and span multiple pages. But most importantly it alleviates
inter-thread locking and contention when passing messages.
Signed-off-by: Sean Cross <sean@xobs.io>
Previously, we would reject buffers that were the maximum allowed size.
This is reported in #141.
Allow these maximally-sized buffers to be printed, since they don't end
up causing a problem.
Signed-off-by: Sean Cross <sean@xobs.io>
just couldn't let it go. figured out the issue is a race condition
in how the Litex UARTs are constructed...I don't know how Litex
normally handles this kind of situation but they have this funky
construction where reading the fifo doesn't advance it, you have
to...clear the pending bit. I think it was meant to be a "clever"
thing that saves an instruction or something like that since you
always have to clear the pending bit.
Anyways, the previous incarnation of this loop checked to see
if the pending bit was set again and if it was it'd run back
and fetch another character. This turns out to be a bad idea
because the pending bit goes through a multireg and other stuff
before it's readable which means it has a lot of delay on it.
This leads to a race condition.
This version actually checks if the fifo is empty and if it isn't,
it reads the character *and* pumps the pending bit (because
the FIFO doesn't auto-advance when you read it, you have to clear
the pending bit).
This works a lot better, but it's not at all well documented how
this works and it's very hard to tell from reading the source code
because it's written using really fancy migen abstractions that
are also poorly documented and have a lot of cursed constructions.
Anyways. At least the console doesn't die now when you type
a control character, *but* you do have the problem that the
escape codes get mis-interpreted sometimes. If it really really
becomes important later on to fix that it would involve tracing
out the sequence of keys that arrive at InjectKey and figuring
out if things are coming out of order or what is triggering the
bad escape codes.
there is still some mysterious problem involving a race condition
of the raw hardware console UART Rx path deciding it doesn't want
to report new characters anymore to the interrupt handler that
is triggered when multi-byte sequences are shoved down the
pipe. So long as you're typing simple commands it's fine, but
escape sequences tend to lock things up. I don't think there's
enough ROI to continue investigating this facility.
this at least removes a panic that crashes processes. it does
mean that some log messages can get silently lost, but this is
better than crashing if the arguments to the logger can't be
parsed for some reason?
This removes all custom string formatting from the `log-server`.
This should improve performance, because we're not roundtripping between
various archive formats. We instead do a single copy and operate
directly on that buffer. We also now write bytes directly, as opposed to
creating intermediate strings.
This fixes a memory issue that was introduced recently.
Signed-off-by: Sean Cross <sean@xobs.io>
Mark the private fields in a `MemoryRange` struct as being private. This
allows us to perform operations on the memory range armed with the
knowledge that the entire range is valid and unaliased.
Signed-off-by: Sean Cross <sean@xobs.io>
Previously, the log server would call `setup` on an uninitialized
struct. This is very undefined behavior, and risked running into
optimization errors.
This reworks the log server such that the singleton is protected by a
`None` value that gets initialized.
Signed-off-by: Sean Cross <sean@xobs.io>
This rewrites the entire project so that most runnable projects now use
`xous-ipc` instead of `xous::String` where possible.
This also removes `rkyv` from the list of dependencies in `xous-rs`.
Signed-off-by: Sean Cross <sean@xobs.io>
Turns out the build time only seems to capture the last time
you managed to force a full rebuild (???). Even though cargo
indicates that a rebuild had happened of the main.rs, the environment
variable containing the time is not being updated, because the
build.rs file isn't being run. But! if you force a trigger of
that file, then cargo decides to rebuild *everything* which greatly
increases the build time, which is a drag for development.
So, just remove the build time notice. If it's not going to be
correct, better to not emit it than to be outright misleading...
Servers will, by default, get randomly-assigned SIDs. Certain servers
will want to have well-known SIDs, such as the log server or the
nameserver. These will use a separate call in order to perform this
priveledged operation.
A subsequent patch will add `CreateServer`.
Signed-off-by: Sean Cross <sean@xobs.io>
This is now able to understand the panic log messages that are sent by
services that are in the procses of panicking.
Signed-off-by: Sean Cross <sean@xobs.io>
