1 Jan
2023
1 Jan
'23
3:52 a.m.
On Sat, Dec 31, 2022 at 4:39 PM Clem Cole <clemc(a)ccc.com> wrote:
On Sat, Dec 31, 2022 at 4:11 PM Dan Cross
<crossd(a)gmail.com> wrote:
Agreed.
I'm going to push back on this slightly:
UEFI+ACPI get a bad rap
because, well, they're really pretty bad. Oh sure, some things are
reasonable: the ACPI table formats aren't awful. But I've been inside
a couple of these now and phew golly, they stink pretty badly.
Fair enough. UEFI+ACPI started from BIOS and really should have been a full re-think
and write by senior OS people. It was not. The problem for us techies, is that
doing that was not going to save or make anyone $s.
The problem for management was they wanted to keep the old BIOS around (that's what
the customer wanted - cheapest path forward) and unless there was a reason to break from
tradition, they were not going too. Apple could (and did) but HP/Dell et al did not want
too.
Yeah. We canc'd it from our product (Oxide machines boot directly from
the x86 reset vector and go almost immediately into Unix; no
BIOS/UEFI+ACPI at all! Of course, there's a bunch of stuff that
happens before the x86 cores come out of reset, but that's a different
kettle of fish). We can get away with this because we control the
hardware and the host software, and the unit of compute our customers
interact with is a virtual machine, not the bare metal. When you
control the horizontal _and_ the vertical, you can put it all in the
host OS, where it arguably belongs. But in a world where software and
hardware are completely decoupled? I don't know how to make the
holistic boot approach work without a lot of system-specific code.
It's obvious that you need some kind of system interface, and for most
vendors, UEFI+ACPI is there and supported by the chip and firmware
vendors, so it's the default. No one ever got fired for using
UEFI/ACPI, I guess.
- Dan C.