> It's less complex to maintain one solution for both types of
boot, I'd
> imagine. I'm not the one that'd be doing the work to support it, so far be
it
> from me to prevent somebody from doing so, but that's just what it sounds
> like. Right now, we have one solution that works well for both.
>
If we wanted to be UEFI first, we could make BIOS boots emulate UEFI
and boot through the UEFI chain all the way through. We already do
this for some boards on ARM with U-Boot, if I remember correctly. If
that were possible on x86, then we could get down to one boot chain
path regardless.
No, U-Boot is the firmware, it now implements a UEFI interface as a
means of interacting with OS/bootloaders for booting OSes in a generic
manner. It's not emulated, it is the interface between the firmware
(U-Boot) and the computer, for aarch64 it's mandated that the board
firmware implement UEFI to be supported in Fedora, whether that's the
Tianocore, U-Boot or another third party implementation, open or
proprietary we don't care.
Why would you wrap BIOS with another firmware implementation? You're
just making the problem worse. Fact is that while it won't go away
particularly fast we should actually be looking at sunsetting
traditional BIOS support, it's not secure or securable. MS has
mandated it for the Windows logo program to be certified HW since
Windows 8, they've now mandated that for server as well, in both cases
now requiring TPM2.
Don't hack up BIOS support, it vaguely sort of works now, leave it
vaguely working and just let it be, it's not evolving. One day we'll
wake up and no one will be using it, the sooner the better.
Peter