Obviously linux itself isn’t going to drop BIOS support, so how much stuff would this let RH get rid of?
I’m asking because everyone seems to agree that UEFI has a better programming model+api, but I can’t see how removing BIOS support makes further improvements to the UEFI code paths
The idea isn’t that removing BIOS support directly improves UEFI, or anything like that. But using BIOS enforces a lot of ancient, weird conventions that require hacks or otherwise complex code to maintain feature parity with UEFI. A lot of these hacks and such are mature, but they’re still extra codepaths to be maintained.
One example that comes to mind: if BIOS support is deprecated, also deprecating MBR Extended Partition support will affect very, very few additional users.
As another example, you don’t really need to support any bootloaders (not counting efistub) if you only support installation on UEFI platforms.
It also makes things like one-button recovery/reset much easier to do the way Apple and Microsoft have made possible on their own systems the past couple of years.
I have mixed feelings about this, because I only recently retired my last non-UEFI machine and it was still for sale 2-3 years ago, but probably quite a lot. The old BIOS model meant that you had to support MBR-based partition tables and bootloaders. This was less of a problem for *BSD than Linux because Linux used MBR partitions directly, whereas BSDs used a single MBR partition and then stuck a BSD partition table inside it. If you want to do something like UFS boot environments then you need at least two root partitions (A/B - one in use, one for installing updates), one partition for user data, and one swap partition. You might also want a separate boot partition. With *BSD, all of these could go in a single MBR partition, with Linux you’d be hitting the limit of MBR partitions if you needed this (and you’re passing it if the user wants to support it). With UEFI and Linux, this is completely fine.
With the legacy BIOS boot process, the first-stage boot loader has to fit in a single disk sector. This then has to find the second-stage loader somewhere else. You can use an XT or PS/2 keyboard in that mode because it’s exposed directly by the BIOS but you don’t have the space for a USB stack, so you can’t use a USB input device during the first stage (which may be when you need to select the physical disk to boot from). Some BIOSes support PS/2 emulation by running a USB stack in the BIOS but often doing this prevents the guest OS from seeing the USB HID and so prevents you from using additional features of the keyboard. With UEFI, the firmware runs a USB stack and exposes services for using it to the bootloader.
All of the work arounds for the old BIOS-style systems increase the complexity of the testing matrix. You can start depending on UEFI functionality for non-optional features of the system. That’s probably a big win.
Obviously linux itself isn’t going to drop BIOS support, so how much stuff would this let RH get rid of?
I’m asking because everyone seems to agree that UEFI has a better programming model+api, but I can’t see how removing BIOS support makes further improvements to the UEFI code paths
The idea isn’t that removing BIOS support directly improves UEFI, or anything like that. But using BIOS enforces a lot of ancient, weird conventions that require hacks or otherwise complex code to maintain feature parity with UEFI. A lot of these hacks and such are mature, but they’re still extra codepaths to be maintained.
One example that comes to mind: if BIOS support is deprecated, also deprecating MBR Extended Partition support will affect very, very few additional users.
As another example, you don’t really need to support any bootloaders (not counting efistub) if you only support installation on UEFI platforms.
It also makes things like one-button recovery/reset much easier to do the way Apple and Microsoft have made possible on their own systems the past couple of years.
I have mixed feelings about this, because I only recently retired my last non-UEFI machine and it was still for sale 2-3 years ago, but probably quite a lot. The old BIOS model meant that you had to support MBR-based partition tables and bootloaders. This was less of a problem for *BSD than Linux because Linux used MBR partitions directly, whereas BSDs used a single MBR partition and then stuck a BSD partition table inside it. If you want to do something like UFS boot environments then you need at least two root partitions (A/B - one in use, one for installing updates), one partition for user data, and one swap partition. You might also want a separate boot partition. With *BSD, all of these could go in a single MBR partition, with Linux you’d be hitting the limit of MBR partitions if you needed this (and you’re passing it if the user wants to support it). With UEFI and Linux, this is completely fine.
With the legacy BIOS boot process, the first-stage boot loader has to fit in a single disk sector. This then has to find the second-stage loader somewhere else. You can use an XT or PS/2 keyboard in that mode because it’s exposed directly by the BIOS but you don’t have the space for a USB stack, so you can’t use a USB input device during the first stage (which may be when you need to select the physical disk to boot from). Some BIOSes support PS/2 emulation by running a USB stack in the BIOS but often doing this prevents the guest OS from seeing the USB HID and so prevents you from using additional features of the keyboard. With UEFI, the firmware runs a USB stack and exposes services for using it to the bootloader.
All of the work arounds for the old BIOS-style systems increase the complexity of the testing matrix. You can start depending on UEFI functionality for non-optional features of the system. That’s probably a big win.