> > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
