Comment by tenebrisalietum

> We called this Advanced Power Management (Advanced because before this power management involved custom drivers for every machine and everyone agreed that this was a bad idea)

Not sure this statement is really true.

An OS has to have drivers for diverse hardware already - an OS will be expected to support devices as varied as keyboards, mice, floppy drives, hard drives, VGA, PCI bus, etc.

I guess it sucks to have to develop 10 drivers for 10 different power management controllers, but:

- the industry could have done what they did for storage - make the controller standard on the hardware level.

and

- if companies could have come together to create ACPI, they could have come together to define standard power management hardware interfaces instead.

> and it involved the firmware having to save and restore the state of every piece of hardware in the system.

APM was a crappy idea too, except if you had to support DOS and things built on it like Windows 3.x and 95.

Ideally the power management controller would just shut the system off, provide something that an OS loader can read to know if the system was powered on cold or resumed, and let the OS be responsible for saving and loading state.

> ACPI decided to include an interpreted language to allow vendors to expose functionality to the OS without the OS needing to know about the underlying hardware.

> How is this better than just calling into the firmware to do it? Because the fact that ACPI declares that it's going to access these registers means the OS can figure out that it shouldn't, because it might otherwise collide with what the firmware is doing. With APM we had no visibility into that

So ACPI provides code your OS must execute with top privileges so it doesn't have to know about the hardware, but it still has to know about the hardware so it doesn't accidentally step on it. Definitely better than the manufacturer of any power management hardware just publishing a datasheet and letting the OS handle it like any other device. /s

> 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

If datasheets were available for the hardware, then open source drivers could be created instead of only relying on closed binary blobs; then those could be mainlined and included with the kernel, and this problem would not exist. The problem is really vendors not releasing information on programming their hardware, not Linux. This goes back to the whole argument: if you pay for and own your hardware, why is the manufactuer able to hide these details from you by not releasing this information?