On Monday, July 6, 2020 3:03:05 PM MST Peter Robinson wrote: > > > 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. That day is still decades away, as others in this list have noted. I agree with the rest, of course. Just let it be. -- John M. Harris, Jr. _______________________________________________ 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
