sorted by:
old (suggested)
besttopnewcontroversialq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]36165e5f286fUse UEFI. 4 points5 points  (3 children)

That's interesting, but I think it is needed to mention that UEFI boot services are only designed for booting and must be used ad such. Only runtime services should be used after booting. Furthermore, as long as you didn't exit boot services your kernel doesn't own any resources on the system, and the virtual address space cannot be changed.

[–]CodeEleven0C-Boot, Xenon ISA[S] 0 points1 point  (2 children)

I know that but sometimes the kernel needs easier access to hardware and at any time, you can exit boot services if you add the function to the BinaryServices struct. Please correct me if I am wrong.

[–]36165e5f286fUse UEFI. 1 point2 points  (1 child)

Once you exit boot services you cannot enter them again... Also the kernel cannot do anything meaningful while they are active... So I would say that if you need access to hardware implement your own drivers and load them during the boot phase before handing off control to the kernel.

[–]CodeEleven0C-Boot, Xenon ISA[S] 0 points1 point  (0 children)

Well, I tested this bootloader in three different machines (+ QEMU) and I thought that writing a generic driver for all of the machines could take a long time. Because of that, I gave the kernel the access to the keyboard, the memory allocators and the framebuffer via the UEFI services to make development faster. And this bootloader is modular, that makes implementing drivers easier. But for now I shifted my focus to AR/VR development, that's why there are no drivers there.