Comment by lmm
1 year ago
> The APM was also tested in practice only with DOS and/or Windows
Right. I'm speculating that since it had only a small number of entry points, Linux tended to end up following the tested codepath. Certainly it broke a lot less on Linux than ACPI does.
Because as much smaller specification that cared about less stuff, it only broke said smaller scope - The things that were cleaned up with ACPI were broken in other components, individual drivers, or simply didn't work due to lack of special drivers with hardcoded data that is instead presented through common way in ACPI.
There's quite a lot of functionality these days that is handled with generic drivers thanks to ACPI that required custom drivers for each device previously (something that OpenFirmware and device tree doesn't fix, as it tends to be slightly less expressive - just information "this device is here" maybe with few attributes, especially if you have only DT and no actual OpenFirmware runtime)
How much does it actually improve? E.g. if it's about having the driver understand the state of the device when coming back from suspend more closely, then I can see how theoretically that might be better - and I can also see how a cruder model with a less detailed interface might end up with higher reliability in practice (at the cost of being notionally slower to wake up and doing more reinitialisation etc. - but that might still end up being a good tradeoff).