There’s an alternative universe where we decided to teach the kernel about every piece of hardware it should run on. Fortunately (or, well, unfortunately) we’ve seen that in the ARM world. Most device-specific simply never reaches mainline, and most users are stuck running ancient kernels as a result. Imagine every x86 device vendor shipping their own kernel optimised for their hardware, and now imagine how well that works out given the quality of their firmware. Does that really seem better to you?
It’s understandable why ACPI has a poor reputation. But it’s also hard to figure out what would work better in the real world. We could have built something similar on top of Open Firmware instead but the distinction wouldn’t be terribly meaningful – we’d just have Forth instead of the ACPI bytecode language. Longing for a non-ACPI world without presenting something that’s better and actually stands a reasonable chance of adoption doesn’t make the world a better place.
Matthew Garrett with the usual paragraphs of wisdom.
This is why I dread the arrival of ARM PCs. Instead of having one Linux ISO that can boot on pretty much anything, it will become more like phones, where someone has to prepare a custom “ROM” for each machine. No thanks!
One ISO that can boot on pretty much anything is how it works in the Arm server world, from what I’ve heard. The Arm ServerReady program, and Red Hat mandating UEFI on servers, is the program for that, and Arm SystemReady is the program, which is derived from the ServerReady program, for the desktop.
Flatland_Spider,
I don’t know what the chances are for these to become a universal standard on all consumer ARM devices…fingers crossed.
BTW have you used any of these server platforms yet? Honestly I’m tempted. Everything I’ve tried to date has the usual gripes about non-mainline kernels and device specific procedures, I’d be thrilled for those problems to be truly behind us.
It’s only needed for machines with support for replaceable hardware and expansion cards. Chances for it ever becoming a standard for mobile phones and laptops are exactly zero. Companies love forced expiration / planned obsolescence.
I think it depends on what Microsoft and Qualacom are going to do with Snapdragon X Elite style processors. are they going to adhere to ServerReady? Anyone know?
I haven’t heard anything, not that I know anything anyway.
I’m not sure either. RPi 4 was SystemReady compliant when booting via UEFI, so there’s that.
> BTW have you used any of these server platforms yet? Honestly I’m tempted.
No. 🙁
Hetzner has Ampere based VPSs, and Ampere dedis, and I’m tempted to rent one of those.
I wonder what’s on eBay….
There’s also an alterative universe where the designers of ACPI did their job properly and standardized the underlying hardware interfaces; so that we only need to teach the kernel about the standardized hardware interfaces once (and don’t need to teach a kernel about every manufacturer’s “completely different for no reason” hardware interfaces).
Instead, we got a standardized software interface (AML methods) that uses a pile of annoying inefficient bloat (an AML interpreter) to shield the OS from unstandardized hardware interface/s (that could’ve and should’ve been standardized but weren’t).
Linux is full of quirks definitions for not-quite-standard USB HID devices… sometimes because the company doesn’t want to pay setup costs for a new revision of the hardware.
How likely do you think a better ACPI would be to change that?
Honestly; I’d expect it’d reduce the number of quirks to maybe 25% of what ACPI has now; because it’d be a lot simpler and better contained (e.g. hardware developers could just do their job without any need to miscommunicate their non-standard hardware details to firmware developers).