[TUHS] Porting the SysIII kernel: boot, config & device drivers

[Dan Cross]

On Sat, Dec 31, 2022 at 4:39 PM Clem Cole <clemc at ccc.com> wrote:
> On Sat, Dec 31, 2022 at 4:11 PM Dan Cross <crossd at gmail.com> wrote:
>> 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.

Agreed.

> 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.