|
|
|
|
|
|
by hbogert
294 days ago
|
|
|
i understand why OP did it. But wouldn't it be nice if we took it all the way and just let the OS figure this out? [1] This is a radical departure from the abstraction-on-abstraction that is implicated by BIOS/UEFI but it feels like it would make the whole architecture not feel like a fossil once it's out of the vendor's hands. This would mean that every OS would need to make an implementation and feels like wasted effort, however, looking at all the BIOS bugs that i encountered which were OS specific, I have to say I'd rather see OS specific implementations than having to convince your vendor that you hit a bug which happens to be on a OS other than Windows or an ancient redhat patched Linux kernel. [1]: https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-... |
|
|
ACPI even included "compatible interface discovery" to handle the possibility that newer features might confuse older OSes without requiring end user to install newer OS (which they might not want to for various reasons) which used to be the norm. I owned a ~1994 UNIX workstation whose manual came with explicit instructions "you need to use at least this specific emergency upgrade version or the OS won't boot". PPC macs despite OpenFirmware had the same issue, because OpenFirmware had no such "interface discovery" mechanism allowing varying interface according to OS being run - it could only specify compatible device identifiers, which was not enough.
Also, you often need (a bit less today, but still important in server systems) considerable amount of vendor-specific drivers in firmware just to get to the OS.
Of course you can also go the completely other way, and implement always-virtualized environment like some IBM POWER systems, where the CPU wakes up with all of hardware already initialized and instruction pointer pointing to hypervisor scheduler loop.