This is less about the OS proper and more about a specific installed configuration - the question isn't "should I use one or the other?" but "should I support both, or is UEFI sufficiently widely used that I don't need to support motherboards that don't have it?" If you decide to support both Legacy BIOS using MultiBoot, and UEFI without MB, then it is up to the OS installer and configuration tools to choose which to use.
The biggest issue here, I think, is not in how the OS boots, but in how it gets the information about the hardware that it needs in order to configure itself at startup - especially the memory map. The difference here is that in MultiBoot, the boot loader is only in memory and runnable up to the point of the hand-off, so anything it needs to give to the OS, it has to do then - the purpose of the Boot Information Table (part of the MultiBoot Header) is to give it somewhere to put that information where the OS can find it.
UEFI, on the other hand, is still resident while the system runs, so - as I understand it - if the OS has support for accessing the UEFI information, then it can get it whenever it chooses. This obviates the need for a header at hand-off, but means the OS needs to know that it is running on a UEFI mobo and have operations for querying it.
You will note that this is primarily an issue in x86 systems with only Legacy BIOS, one due primarily to the lack of a 32-bit version of the BIOS routines - exactly what UEFI is meant to fix for x86. In systems using UEFI, or ones using other processors (ARM, MIPS, etc.), the BIT is mainly a matter of convenience, though some configurations may still have information that is only accessible at boot-up.
This is also why, when MB-compliant boot loader loads a system that doesn't support a MBH (and hence won't use a Boot Information Table), it has to chain boot, and why chain booting on x86 doesn't switch to p-mode - the OS has to be able to get that information from the BIOS on its own, which means the OS has to be able to access the 16-bit BIOS. Presumably, such systems (e.g., Windows) anticipate booting into real mode anyway, so switching first would actually cause the start-up to fail.
_________________ Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF Ordo OS Project Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.
|