I'm usually always lurking in this type of communities, but since I'm a condemned procastinator that demands INSTANT GRATIFICATION, I had never enough patience and willpower to actually learn programming myself, and chances are that I will never get enough skills to be able to make decent progress in an involved project like an OS is. Still, I love to see other people progress, and I always have fun reading comments from people that develops hobby OSes and program in Assembler, or throwing ideas myself.
The reason of this Post is that something called heavily my attention: UEFI specifications, besides its powerful pre-boot enviroment, allows for the creation of "Runtime Drivers", which can be called by the OS after the infamous UEFI ExitBootService() that finishes the pre-boot stage is invoked, and these Drivers live until system shutdown. So far, I occasionally google this matter and in years I couldn't find someone else either claiming to be implementing them, or asking about them, so I don't recall seeing any discussion about this matter to see the pros and cons of moving the Drivers to the UEFI layer.
Some of the things I could think about:
-OS independence: Runtime Drivers would be OS independent. Assuming people can manage to standarize a framework, naming convention, how to deal with Hardware Devices of the same type but with vastly different capabilities, etc, the end result would be something similar to BIOS Interrupts (INT x). Instead of each OS needing its own Drivers to initialize and set up the Hardware, an UEFI aware OS could rely on UEFI having preinitialized the Devices.
The usefulness of this is that Driver development and OS development wouldn't be so close any more. As far that I know, nearly every hobbyst had to reimplement the same set of basic Drivers everytime they wanted to do something (USB support, video acceleration, etc). This may partially tackle that. People that likes Hardware interaction could fine tune the Drivers to get the most out of the Hardware (Be it in features or in speed via optimizations), while people caring about the "user experience" (In marketing terms, heh) could focus more on how the OS would work to be useful and functional instead of having to learn all the quircks of each piece of Hardware to make it work. It would look very similar to the Linux world where you have the main Linux Kernel, then a lot of distributions using it or tweaking it for their own needs.
-Bare Metal (Type I) Hypervisors: I became a fan of virtualization a few years ago, since with a good infrastructure, virtualization is ridiculous versatile. Why focusing on a single OS, when you can run in parallel all them?
The most interesing Hypervisors are the Bare Metal ones. One of such exist, which is Xen. Xen can be optionally compiled as an EFI Executable and thus be loaded directly by the UEFI Firmware, you could even skip having a Boot Loader/Manager if your UEFI Firmware allows you to manually choose with EFI Executable you want to load. However, Xen has a sort of drawback: While the Hypervisor itself is bare metal, it has no Drivers and a lot of other things of its own, thus it instead relies on an administrative domain (Called Dom0), which is usually a Linux distribution, to provide Drivers and management tools. Since Dom0 could be either a minimalistic console based distribution or a full blown one with GUI like Ubuntu, being Bare Metal becomes trivial since the end result is that in usage is extremely close to KVM for Linux, which is a Type II Hypervisor. And both relies on QEMU for the emulation of Devices inside the VM anyways, making them even more closer...
Previously, during 2008 there was an interesing development about Bare Metal Hypervisors:https://www.blackhat.com/presentations/ ... Slides.pdf
This project would have loved UEFI Runtime Drivers, since it could allow to augment a Bare Metal Hypervisor before even loading an OS. To be honest, I would believe that a Bare Metal Hypervisor should be fully functional in the UEFI pre-boot enviroment, instead of needing an OS to fill the missing gaps, which is why UEFI Runtime Drivers would be critical for it. However, no such other projects about this surfaced in nearly a decade as far that I know. Nor I know if such Driver could be as complex and full-featured as an OS Driver, since there is a lack of them to begin with.
I would like to know if someone else has experience, or thoughts on the potential and use cases of these Runtime Drivers.