Currently, the uefi-services crate contains a panic handler, while this is useful, It is a problem if you are doing printing yourself as you can't use your own printer for panics. The best option would be to make the panic handler optional using cfg_attr()

Thank you for your time!

The stage2 disk image must remain under 64kB to allow loading it in a single bios int 13H call from within stage1. While we don't want stage2 to get any larger, this can be a show stopper when stage2 code compiled with debug code or lower optimization causes this boundary to be exceeded.

Investigate improving the stage1 bootloader to make multiple bios calls to fulfill the stage2 read if needed

Although a new inline assembly syntax asm! was announced in Rust on 2020/06/08[1], KRaBs still uses llvm_am!.

[1] New inline assembly syntax available in nightly

According to the blog, the asm! macro should be safer and easier to use. This is expected to become the mainstream of inline assembly in the future, so

display_bsod internally calls the map_framebuffer syscall to map the framebuffer, because we . were lazy and didn't want to duplicate code. However this syscall retrieves the current process to map it in its process memory.

When we're panicking during early boot, CURRENT_PROCESS is None and this panics in the panic handler.

We should instead do a second function that maps it in the k

the binary memory map describes only one space, starting with the physical address 0x00100000
process the rest of the memory map entries and describe them in a binary memory map