[shrubble]

I could see myself supporting OpenFirmware which is a fraction of the size and complexity of UEFI and has a very limited attack surface. You could literally boot up a SPARC machine across the Internet with OFW in the mid 1990s, if you’re worried about functionality. And for configuring your system it’s simple and straightforward. The OLPC laptops used it, so it’s already somewhat proven on ARM.

[p_l]

And a major issue with OpenFirmware was that like other comparable interfaces from its time it required you to release a new OS version to support a new machine if it used different devices.

Something as simple as handling evolution in available steps in backlight control can require updated OS build on OpenFirmware.

ACPI was built for a world where a newly released computer had to still boot properly a system that predated it, which is major source of complexity in its bytecode.

[shrubble]

I’m not sure I’m following you; wouldn’t a driver solve that issue? You don’t have to release a new OS build for a new PCI card being released…

[p_l]

Backlight is a trivial example.

In the past it meant you were unable to even boot the install media, these days it often means something might boot but ends up stuck because it can't initialize for example input devices so you can't load extra driver - which you first need. For every OS you want to boot.

EDIT: In fact, I have a funny example. On my laptop, out of laziness, vendor didn't include necessary ACPI data for sound to work properly.

Why?

Because for windows they could just ship a minimal INF file that declared a "driver" for the speakers which was actually just collection of parameters for a generic driver. As we say in Poland, "finished, time for Counter Strike".

On Linux working sound required patching drivers to include potentially dangerous settings as "quirks", including things like capacitance of capacitors connected to amplifiers.