PeterX wrote:
I have the impression I was overestimating UEFI all the time:
Question 1.) Is UEFI an important fundament of runtime functions for the kernel, like BIOS interrupts were for DOS?
Definitely NOT. DOS was lucky so that it could stand on the shoulders of BIOS for I/O.
PeterX wrote:
Or is it more like BIOS and 32bit OS where interrupts normally are used only at boot time?
More like it. 99% of UEFI is completely USELESS after exit Boot Services.
PeterX wrote:
And I thought of all use cases for EFI I can imagine and came up with these:
- turn off watchdog timer
- get mem map
- get video mode
- set video mode
- exit boot services
- load kernel helper files (similar to initial ramdisk)
- boottime messages (diagnostics or bootloader)
- boottime input (bootloader)
Forget ALL of these! These aren't runtime services, a kernel can't use any of these. For example DOS could read a sector into memory using BIOS, but your kernel can't use UEFI Block IO to do the same, you'll have to write a native driver!
PeterX wrote:
Question 2.) Can you name further use cases for UEFI functions?
No! Everything UEFI runtime services provide is a lot simpler to achive without using UEFI. Getting the time? Using a few IO commands is a lot simpler than generating an MS ABI conformant call and parsing it's time structure. Reset the computer? Just do a triple-fault, works 100% of the time. Shutdown? That's not even possible with UEFI, needs a native ACPI driver anyway. Using UEFI variables? Why on earth would anyone do that except for setting the boot order occassionally? Setting virtual map? All kernels will change CR3 directly sooner or later...
That being said, it's not the usefulness of UEFI that's the question. That's the only thing you can use to boot your kernel, so you must support it, whether you like it or not. We must cook from the ingredients we got.
Cheers,
bzt