Comment by lmm
1 year ago
And yet somehow APM-based systems broke a lot less often. If the only codepath that's ever going to be tested is "what windows does", maybe having a cruder API that doesn't expose so many details of what's happening (and instead just lets the BIOS opaquely do its thing) is the way to go?
Pretty much only laptops had APM at first. Hardware didn't change much on laptops. I still had to unplug the ethernet cable from my PCMCIA card every now and then to get it to sense the link, but it wasn't that bad once I got all the right linux patches.
Then power management moved into desktops and servers that had expansion slots and everything became horrible.
The APM was also tested in practice only with DOS and/or Windows (and not all Windows, which could also be an issue).
And yes, it really didn't work well with dynamically attachable devices that might have important state.
> 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)
1 reply →