There are numerous areas in the kernel where a heap allocation failure is being silently ignored, merely asserted against or otherwise mishandled. Assertions may suffice for allocations on initialization (where system bringup would otherwise be impossible), but allocation failures which may reasonably happen during runtime must be addressed.

See, for example, #1199; all the various calls to the

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

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

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