Open emilkovacev opened 1 year ago
I like this idea but I'm not sure what the best way to implement this is. Should we put it in a file? Output it over serial? Print to the screen? Would all errors be handled the same (are some errors are more serious than others)?
I'd love to hear yours, and others, thoughts on this
I suppose it depends on how granular we want to be about this. Personally, I think we should print a big 'ol error log to the screen and crash immediately.
As an example, let's say I'm executing bootloader interrupts. If the interrupt fails along the way, there are a number of checks along the way that indicate that, but there isn't really anything meaningful to do when it does (as of now). I prefer crashing instantly to other options, because it will encourage us to solve those issues as they arise, or see if other changes silently affect ones later in the stage of the build.
I'm definitely open to expanding this into more issues though, those are great features that should be implemented too!
Is there an existing issue for this?
Is this a new feature or an enhancement?
Enhancement
Feature Description
Just like in any kernel, we should be able to recover from any error in any part of the kernel and log it. This will help us diagnose issues within the kernel early on in development.
Implementation Notes
Description
This issue will require 2-3 functions that could be called any time a sanity check fails: one in 16-bit mode (bootloader), one for 32-bit mode (bootloader), and one for 32-bit code (in
main.c
or any libraries called by it). In both the bootloader and C code, this function should print an error to the console and crash.The scope of this issue is to simply implement the helper functions – adding sanity checks is outside the scope of the issue (and will require issues in the future).
Labels/Assignees