Bottomley: Owning your Windows 8 UEFI Platform [LWN.net]

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 20:17 UTC (Thu) by raven667 (subscriber, #5198)
In reply to: Bottomley: Owning your Windows 8 UEFI Platform by mirabilos
Parent article: Bottomley: Owning your Windows 8 UEFI Platform

GRUB isn't the BIOS/firmware, its a bootloader. If you made GRUB part of the BIOS/firmware and add the requirements for initializing the hardware then what you would get would look like EFI. Your suggestion is an argument against the BIOS not in favor of it, since it clearly doesn't have the features you want since your first inclination is to load something else. There is no architectural benefit to building your full featured environment on top of the BIOS rather than just replacing it and providing a BIOS compatibility layer, which is what EFI does.

to post comments

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 20:30 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (6 responses)

No because GNU GRUB is just *one* implementation, and I have my own – BSD boot(8/i386) if you care.

And all implementations have a not too small, not too big set of things to work with and full machine control, unlike with EFI (one early but big #FAIL of it being that Apple machines run a 32-bit EFI which then can only boot a 32-bit kernel, not a 64-bit anything; couldn’t happen with BIOS things, as long as the machine is amd64 capable; this led to Apple supporting running 64-bit userspace with a 32-bit kernel, now isn’t *that* schizo?) which offers so many services that you can, but also *have* to use, and disables or actively breaks direct hardware access and other, older methods of doing things (BIOS is compatible down to 1981 – assuming you’ve got a 5¼" floppy somewhere, I do).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 21:52 UTC (Thu) by raven667 (subscriber, #5198) [Link] (5 responses)

Does a modern chipset even have the appropriate interface for plugging in a 5¼ floppy? Is that anything other than dead code? I actually have used a 5¼ floppy drive in the last year, with a USB interface, not direct connected to the motherboard.

If you had to design the firmware for a modern machine would it look anything like the BIOS? Or would it look more like EFI or GRUB with a command interface and a standard way of driving graphics, input, disk and network devies in a modular way.

Why does a high-capability bootloader even need to exist, shouldn't the machine just be able to load your OS kernel directly?

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 22:14 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (1 responses)

I’d probably design something a bit more featured than a BIOS, but definitely not as much as EFI. No command shell either, but definitely something that supports a serial console as first tier input/output like Sun OpenBOOT does.

Or I’d just use OpenBOOT. I mean, OpenFirmware existed, and was used left and right in the industry, before EFI came to be. It’s not without its own problems (such as, initialising only the first four megs of RAM on my SPARCstation) but not as crazily huge either.

Bootloaders are extensible. New filesystems. Network boot, even http. iSCSI. AOE. nbd. New operating systems. Co-processors that turn a computer of one architecture, say an m68k Amiga, into something entirely different, such as a PowerPC machine (those cards do exist and are supported by Linux, so this is not just speculation, although I’ve not seen something similar for PCs in the last decade; I don’t limit my horizon to PCs though).

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 21, 2013 23:34 UTC (Thu) by raven667 (subscriber, #5198) [Link]

So its definitely not the functionality of EFI that you are objecting to, since OpenBoot has much the same functionality, a CLI, etc. it's the specification or the implementation of EFI that you object to?

I don't know much about it but I can guess at the reasons why Intel decided to create EFI rather than extend OpenBoot, it may not have been available at the time or the firmware developers may not have wanted to work with Forth. There are probably other, technical, reasons why Apple didn't port it to x86 and ported EFI, which had been Itanium only, instead.

I don't have a strong opinion on the EFI implementation but I think we both agree that it has the infrastructure to solve the problem in a better way than the BIOS. Or maybe we disagree what the problem space is?

shouldn't the machine just be able to load your OS kernel directly?

Posted Mar 1, 2013 1:00 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

How will it know where to find the kernel?

More to the point, how will the bios be able to tell the kernel all the important options it needs to know?

Your bios will be like LILO (which had to be re-installed every time you made a change to the kernel). Or like CP/M (which had to do a "sysregen" every time the hardware changed).

Cheers,
Wol

shouldn't the machine just be able to load your OS kernel directly?

Posted Mar 1, 2013 1:15 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Well this horse might already be out of the stable with UEFI but creating a way to make variables available to the kernel image doesn't seem impossible, maybe stored as EFI variables in a standard way, or as files on the boot filesystem. How did HPUX boot? That's what EFI was designed for. Maybe the tools aren't there now because there wasn't enough participation by Linux vendors or the Linux Foundation when these issues were decided, no one is going to hand you a seat at the table for these kinds of things, you have to insert yourself worth force if you don't want to be run over.

shouldn't the machine just be able to load your OS kernel directly?

Posted Mar 1, 2013 1:35 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

EFI has that information stored in the nvram boot variables.