You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of having a dedicated serial line for the debug logs, an idea could be to send them to the main (and likely only) serial line until the kernel has started. From there, we can avoid showing them because that would mess with the "UI" (e.g., kshell).
We could use a pseudo-file to show them if needed (e.g., we would use a ring buffer to store the logs exposed via the proc fs). It is going to work well until the system crashes, though because we'll lose everything probably. We could dump all the logs in PANIC() but, if it is a different crash, like unexpected, we'll be left without anything.
Another idea could be to use a feature flag for this?
The text was updated successfully, but these errors were encountered:
Lately, I started to print INFO logs to the main output (e.g., screen or serial).
For DEBUG logs, especially on real hardware, we probably want them in a file as opposed to printed on the screen or serial, even if it is a second serial line.
For local dev, maybe there is a semihosting feature that we could leverage somehow?
Instead of having a dedicated serial line for the debug logs, an idea could be to send them to the main (and likely only) serial line until the kernel has started. From there, we can avoid showing them because that would mess with the "UI" (e.g., kshell).
We could use a pseudo-file to show them if needed (e.g., we would use a ring buffer to store the logs exposed via the proc fs). It is going to work well until the system crashes, though because we'll lose everything probably. We could dump all the logs in
PANIC()
but, if it is a different crash, like unexpected, we'll be left without anything.Another idea could be to use a feature flag for this?
The text was updated successfully, but these errors were encountered: