8 ms·

Why ACPI?

266 points by ingve 3y ago

ez_mmk 3y ago
Does anyone have a link to the 12k page long discussion?
- kryptiskt 3y ago
  It's a meme, there isn't such a thread (probably). I mean, there is no lack of flame wars about ACPI out there, but that megathread mention is a meme used about controversial subjects.
- aseipp 3y ago
  It's a reference to a famous Twitter post: https://twitter.com/dril/status/107911000199671808 https://twitter.com/dril/status/107911000199671808
  - jancsika 3y ago
    I really wish web denizens would use memes with their own local color which, when applicable, are also true. I mean, I'm sure Matthew knows some really long, legendary Linux Kernel Mailing List thread that is at least somewhat related to this post. It would be fun because then we could click the hyperlink, and Linux Kernel Mailing List threads are nothing if not dramatic. :) Instead, here every web tribe localizes a meme that traces back to a dead end Tweet. So instead of getting to travel back to the actual tribe's colorful flame history, I get the tribe's low-effort localization of a dead Twitter stump. Boo!
tux3 3y ago
I would like to offer a prophecy: For the next evolution of ACPI, Linux kernel devs (employed at hardware companies) will figure out a way to replace the bespoke bytecode with eBPF. Windows will, of course, spawn a WSL instance when it needs to interact with ACPI. macOS is its own hardware platform, and will naturally come up with their own separate replacement.
- kryptiskt 3y ago
  There already is an eBPF for Windows, it's even Microsoft's own project https://github.com/microsoft/ebpf-for-windows https://github.com/microsoft/ebpf-for-windows
  - 6th 3y ago
    Ahh. Just as the prophecy foretold.
- _trackno5 3y ago
  macOS already uses (at least on ARM chips) device trees. I don’t see why they would go back to ACPI as long as they keep their SoC model.
- mschuster91 3y ago
  > macOS is its own hardware platform, and will naturally come up with their own separate replacement. Actually, no. The M-series SoCs use device trees [1], and in fact their Apple SoC predecessors did just as well - the earliest I could find is the iPhone 3GS [2]. [1] https://lore.kernel.org/lkml/20230202-asahi-t8112-dt-v1-0-cb5442d1c229@jannau.net/T/ https://lore.kernel.org/lkml/20230202-asahi-t8112-dt-v1-0-cb... [2] https://www.theiphonewiki.com/wiki/DeviceTree https://www.theiphonewiki.com/wiki/DeviceTree
  - monocasa 3y ago
    They're very device tree oriented. They've been using them since "new world PowerPC" Macs in the 90s. Even on x86, their boot loader constructs a device tree to describe the hardware to the kernel.
    - surajrmal 3y ago
      They have no incentive to use or benefit from ACPI. They don't have the problem of trying to scale to an innumerable number of hardware permutations. They have a limited set which they control the entire stack of. I would certainly be very confused if they went with such an overkill solution as well.
Quentincestino 3y ago
I still cannot understand your problem with Device Trees after reading your article, I used to write a ARMv8 and a x86 kernel and found out that ACPI and Device Trees had same capacities, but less headhaches with DT.
- Joker_vD 3y ago
  Where do the device trees come from?
  - KirillPanov 3y ago
    The same place ACPI tables come from. A flash chip on the motherboard.
    - pabs3 3y ago
      Usually they are shipped with the Linux kernel rather than mobo flash.
      - Joker_vD 3y ago
        How does the kernel knows which of the many possible device trees describes my hardware? Or is the system comes with custom-compiled pre-installed Linux kernel, with the one correct DT baked into it by the manufacturer?
        surajrmal 3y ago
        ARM devices almost always need custom kernels. Even if you had device tree provided to you, there isn't a lot of confidence the kernel will be able to perfectly parse it nor have all the necessary drivers. This isn't an arm specific issue but rather an ecosystem issue as no one drives standardization.
        NewJazz 3y ago
        U-Boot or something else tells the kernel which DT to use, and gives its own DT to the kernel. If Linux has its own DT for the hardware, it will use that. Otherwise it falls back to what the bootloader provided.
jdblair 3y ago
I remember when I built a new PC, with some socket 370 pentium or another, around 2002. I ran an i2c probe to find the addresses to read the fan tachometer. The scan wrote some bits that irrecoverably messed up the firmware, the board wouldn't boot and I replaced it.
- rasz 3y ago
  Asus must have anticipated trouble because their boards from that time period hide I2C bus away by default :) You have to do special port knocking incantation to expose it https://www.vogons.org/viewtopic.php?p=1173247#p1173247 https://www.vogons.org/viewtopic.php?p=1173247#p1173247 >They share i2c bus between clock generator/monitoring chip and ram SPD using a mux. If you switch this mux and forget to switch it back computer will have trouble rebooting because bios blindly assumes its always set to clock gen.
KirillPanov 3y ago
[flagged]
lmm 3y 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?
- mzs 3y ago
  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.
- p_l 3y ago
  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.
  - lmm 3y 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.
    - p_l 3y ago
      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)
dcomp 3y ago
I'm only slightly familiar with the specific features ACPI provides. But isn't the solution the following For every "feature" provided by the SMM or bios. Export a UUID ( eg NVME resume implementation1) Have that feature have an enable and disable function. Have each feature have a dependency on each iorange / firmware device it needs access to. If the kernel know how to implement the feature it can just disable the feature and then as long as it follows the dependency tree and can see nothing else accesses those ranges. It can know that it has exclusive use. If it doesn't have exclusive use it must use the firmware to access those ranges if possible or fall back to no support If the firmware has a feature without a disable function. The kernel knows it can never access that hardware directly/safely. You could even have a "lock device" that if you take you know that SMM won't access those io ranges whilst you have the lock. Obviously this all requires vendor support
- mjg59 3y ago
  This is actually how things are meant to work! Many ACPI features are gated behind a _DSM call that allows the OS to indicate that it has native support for functionality and the firmware should stop touching it itself. It, uh, basically works to the extent that Windows makes use of it.
PaulHoule 3y ago
I find it kind of amusing that the dynamic configuration problem of hardware is so tough and think about the old mainframe and minicomputer OS of the 1970s which avoided all that by starting out with some configuration that supported one terminal and limited storage devices and would recompile the OS for the exact hardware configuration of the machine and print it to a paper tape or magnetic tape and they'd boot off that. Thus you had a "systems programmer" at every mainframe installation. That part of the industry got into dynamic configuration to support hot plugging and generally being able to change the hardware configuration without causing downtime.
- teunispeters 3y ago
  Ah back when the whole supply chain had a single manufacturer and no one worried about whether someone might want to put in - say - two video cards or the like. Apple still kind of exists in this space.
  - PaulHoule 3y ago
    Wasn't like that all with DEC and I don't think so with IBM mainframes either. It was common for DEC systems to have custom Unibus cards https://en.wikipedia.org/wiki/Unibus https://en.wikipedia.org/wiki/Unibus as these were really easy to make. They dealt with them by building custom drivers right into the OS when they build an OS image. Circa 2002 a friend of mine developed custom printer interfaces and drivers for IBM z because IBM's printer interface couldn't support the high rate of printing that New York state needed to satisfy the mandate that any paperwork could be turned around in 2 days or less. Whatever you say about NY it is impressive how fast you get back your tax returns, driver license, permit to stock triploid grass carp or anything routine like that.
    - p_l 3y ago
      But it also meant that release of a new computer often required new OS release, with DEC often patch releases that added just enough code to run the devices included in new computer, because the older versions would at best boot into something unusable. As for IBM mainframes, the list of devices directly attachable at OS level is quite small, and even then application with appropriate privileges could directly send control words to a channel. That said, things like printers would probably be intermediated by communication controllers translating from channel interface to serial lines.
manonthewall 3y ago
As someone who had to test various ACPI configs and work my way through the docs, I will never do that again. I will literally get out of my seat and tender my resignation on the spot if they try to force me. Never again. It's probably the most overengineered thing I've ever had to work with.
ajross 3y ago
This is all absolutely true, but it's not really an argument for or against ACPI or DTS or OF or any of that stuff. They're all sort of messy, but frankly all aimed at solving the wrong problem. The root cause to every single problem in this space is simple: the OS and the firmware need to coordinate, period. That's a software problem. It's a complicated software problem. And it has to be solved with software engineering, with stuff like interface specifications and division of responsibilities and test suite and conformance tests and all the other boring stuff. And ACPI is, sure, a reasonable language for expressing most of that work. But... no one does the work![1] Vendors make windows run and then ship it, and will occasionally fix bugs reported by critical customers. And that's all you get. Linux comes along later (even new versions of Windows often have crazy workarounds as I understand it) and needs to piece together whatever the firmware is doing ad hoc, because none of those vendors are going to bother with anyone that isn't Microsoft. [1] In the PC world. In the world of integrated hardware things are much better. You can rely on your Mac or your Chromebook or your Galaxy S412 not to have these kinds of bugs, not becuase they use better firmware interface languages (arguably they don't -- I've seen DTS trees for ARM chromebooks!), but because they treat this as a software problem and have the firmware and OS teams work with each other.
- mjg59 3y ago
  The problem with the PC world is that the firmware and OS teams are not only working for different companies, they're working on different timescales and release cadences. Android devices and Macs are in an entirely different situation here, so the only really comparable example is the Chromebook - and that's a market where if Google doesn't want to support your hardware you don't get to ship it.
  - ajross 3y ago
    The point isn't that they're comparable, obviously they aren't. It's that the techniques used to solve the problem (synchronize "timescales and release cadences" in your example) are engineering management things and not technologies. It's true that "Linux vs. Lenovo" doesn't have the same engineering practice tools available. But... evangelizing technological tools like "ACPI" isn't a path to a solution, because... those tools just don't work. Or rather they don't work in the absence of someone addressing the engineering practice problem. They work fine to do what they're designed to do. But what they're designed to do emphatically isn't "Make Lenovo Hardware Work With Linux".
crabbone 3y ago
The only reason I know ACPI exists is because every Linux laptop I ever had always spit a roll of error messages related to ACPI (and usually no support). My understanding is that on top of the inherent problems outlined in the article, there's a more trivial problem of vendors not caring enough to do this right. So, typical for Linux laptops, hybernation and many other forms of power-saving either don't work at all, or are broken (eg. a laptop never wakes up from hybernation, or just the screen never wakes up etc.)
- mjg59 3y ago
  These days most of these failures are bugs in the Linux drivers, not bugs in the firmware. The Lenovo case I mention in the article is actually unusual in that respect.
somat 3y ago
There are three ACPI stacks. The reference intel one, this is what linux, macos and freebsd uses. The microsoft one. and finally those madlads over at the openbsd project have their own. good for them.
- ChickeNES 3y ago
  Four: https://github.com/managarm/lai https://github.com/managarm/lai
eismcc 3y ago
I worked on windows kernel team and my first real projects were ACPI 1 and 2 implementation. It's been a while and ACPI was well on its way when i got there, the story at the time was that huge gaps in BIOS were problem and we need to move it into the kernel. There was also a big push from the industry at the same time to use EFI to allow devices to have a pre-os experience (e.g. play DVDs) and not be dependent upon Windows for those. Another memory I have for that time was that powermgmt was a big priority. So i suspect the ability for the OS to do that via ACPI was strategic - I wasn't involved in the decision making.
tenebrisalietum 3y ago
> 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?

Why ACPI?

266 points by ingve 3y ago

ez_mmk 3y ago

Does anyone have a link to the 12k page long discussion?

kryptiskt 3y ago
It's a meme, there isn't such a thread (probably). I mean, there is no lack of flame wars about ACPI out there, but that megathread mention is a meme used about controversial subjects.
aseipp 3y ago
It's a reference to a famous Twitter post: https://twitter.com/dril/status/107911000199671808 https://twitter.com/dril/status/107911000199671808
- jancsika 3y ago
  I really wish web denizens would use memes with their own local color which, when applicable, are also true. I mean, I'm sure Matthew knows some really long, legendary Linux Kernel Mailing List thread that is at least somewhat related to this post. It would be fun because then we could click the hyperlink, and Linux Kernel Mailing List threads are nothing if not dramatic. :) Instead, here every web tribe localizes a meme that traces back to a dead end Tweet. So instead of getting to travel back to the actual tribe's colorful flame history, I get the tribe's low-effort localization of a dead Twitter stump. Boo!

tux3 3y ago

I would like to offer a prophecy: For the next evolution of ACPI, Linux kernel devs (employed at hardware companies) will figure out a way to replace the bespoke bytecode with eBPF. Windows will, of course, spawn a WSL instance when it needs to interact with ACPI. macOS is its own hardware platform, and will naturally come up with their own separate replacement.

kryptiskt 3y ago
There already is an eBPF for Windows, it's even Microsoft's own project https://github.com/microsoft/ebpf-for-windows https://github.com/microsoft/ebpf-for-windows
- 6th 3y ago
  Ahh. Just as the prophecy foretold.
_trackno5 3y ago
macOS already uses (at least on ARM chips) device trees. I don’t see why they would go back to ACPI as long as they keep their SoC model.
mschuster91 3y ago
> macOS is its own hardware platform, and will naturally come up with their own separate replacement. Actually, no. The M-series SoCs use device trees [1], and in fact their Apple SoC predecessors did just as well - the earliest I could find is the iPhone 3GS [2]. [1] https://lore.kernel.org/lkml/20230202-asahi-t8112-dt-v1-0-cb5442d1c229@jannau.net/T/ https://lore.kernel.org/lkml/20230202-asahi-t8112-dt-v1-0-cb... [2] https://www.theiphonewiki.com/wiki/DeviceTree https://www.theiphonewiki.com/wiki/DeviceTree
- monocasa 3y ago
  They're very device tree oriented. They've been using them since "new world PowerPC" Macs in the 90s. Even on x86, their boot loader constructs a device tree to describe the hardware to the kernel.
  - surajrmal 3y ago
    They have no incentive to use or benefit from ACPI. They don't have the problem of trying to scale to an innumerable number of hardware permutations. They have a limited set which they control the entire stack of. I would certainly be very confused if they went with such an overkill solution as well.

Quentincestino 3y ago

I still cannot understand your problem with Device Trees after reading your article, I used to write a ARMv8 and a x86 kernel and found out that ACPI and Device Trees had same capacities, but less headhaches with DT.

Joker_vD 3y ago
Where do the device trees come from?
- KirillPanov 3y ago
  The same place ACPI tables come from. A flash chip on the motherboard.
  - pabs3 3y ago
    Usually they are shipped with the Linux kernel rather than mobo flash.
    - Joker_vD 3y ago
      How does the kernel knows which of the many possible device trees describes my hardware? Or is the system comes with custom-compiled pre-installed Linux kernel, with the one correct DT baked into it by the manufacturer?
      - surajrmal 3y ago
        ARM devices almost always need custom kernels. Even if you had device tree provided to you, there isn't a lot of confidence the kernel will be able to perfectly parse it nor have all the necessary drivers. This isn't an arm specific issue but rather an ecosystem issue as no one drives standardization.
      - NewJazz 3y ago
        U-Boot or something else tells the kernel which DT to use, and gives its own DT to the kernel. If Linux has its own DT for the hardware, it will use that. Otherwise it falls back to what the bootloader provided.

jdblair 3y ago

I remember when I built a new PC, with some socket 370 pentium or another, around 2002. I ran an i2c probe to find the addresses to read the fan tachometer. The scan wrote some bits that irrecoverably messed up the firmware, the board wouldn't boot and I replaced it.

rasz 3y ago
Asus must have anticipated trouble because their boards from that time period hide I2C bus away by default :) You have to do special port knocking incantation to expose it https://www.vogons.org/viewtopic.php?p=1173247#p1173247 https://www.vogons.org/viewtopic.php?p=1173247#p1173247 >They share i2c bus between clock generator/monitoring chip and ram SPD using a mux. If you switch this mux and forget to switch it back computer will have trouble rebooting because bios blindly assumes its always set to clock gen.

KirillPanov 3y ago

[flagged]

lmm 3y 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?

mzs 3y ago
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.
p_l 3y ago
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.
- lmm 3y 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.
  - p_l 3y ago
    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)

dcomp 3y ago

I'm only slightly familiar with the specific features ACPI provides. But isn't the solution the following For every "feature" provided by the SMM or bios. Export a UUID ( eg NVME resume implementation1) Have that feature have an enable and disable function. Have each feature have a dependency on each iorange / firmware device it needs access to. If the kernel know how to implement the feature it can just disable the feature and then as long as it follows the dependency tree and can see nothing else accesses those ranges. It can know that it has exclusive use. If it doesn't have exclusive use it must use the firmware to access those ranges if possible or fall back to no support If the firmware has a feature without a disable function. The kernel knows it can never access that hardware directly/safely. You could even have a "lock device" that if you take you know that SMM won't access those io ranges whilst you have the lock. Obviously this all requires vendor support

mjg59 3y ago
This is actually how things are meant to work! Many ACPI features are gated behind a _DSM call that allows the OS to indicate that it has native support for functionality and the firmware should stop touching it itself. It, uh, basically works to the extent that Windows makes use of it.

PaulHoule 3y ago

I find it kind of amusing that the dynamic configuration problem of hardware is so tough and think about the old mainframe and minicomputer OS of the 1970s which avoided all that by starting out with some configuration that supported one terminal and limited storage devices and would recompile the OS for the exact hardware configuration of the machine and print it to a paper tape or magnetic tape and they'd boot off that. Thus you had a "systems programmer" at every mainframe installation. That part of the industry got into dynamic configuration to support hot plugging and generally being able to change the hardware configuration without causing downtime.

teunispeters 3y ago
Ah back when the whole supply chain had a single manufacturer and no one worried about whether someone might want to put in - say - two video cards or the like. Apple still kind of exists in this space.
- PaulHoule 3y ago
  Wasn't like that all with DEC and I don't think so with IBM mainframes either. It was common for DEC systems to have custom Unibus cards https://en.wikipedia.org/wiki/Unibus https://en.wikipedia.org/wiki/Unibus as these were really easy to make. They dealt with them by building custom drivers right into the OS when they build an OS image. Circa 2002 a friend of mine developed custom printer interfaces and drivers for IBM z because IBM's printer interface couldn't support the high rate of printing that New York state needed to satisfy the mandate that any paperwork could be turned around in 2 days or less. Whatever you say about NY it is impressive how fast you get back your tax returns, driver license, permit to stock triploid grass carp or anything routine like that.
  - p_l 3y ago
    But it also meant that release of a new computer often required new OS release, with DEC often patch releases that added just enough code to run the devices included in new computer, because the older versions would at best boot into something unusable. As for IBM mainframes, the list of devices directly attachable at OS level is quite small, and even then application with appropriate privileges could directly send control words to a channel. That said, things like printers would probably be intermediated by communication controllers translating from channel interface to serial lines.

manonthewall 3y ago

As someone who had to test various ACPI configs and work my way through the docs, I will never do that again. I will literally get out of my seat and tender my resignation on the spot if they try to force me. Never again. It's probably the most overengineered thing I've ever had to work with.

ajross 3y ago

This is all absolutely true, but it's not really an argument for or against ACPI or DTS or OF or any of that stuff. They're all sort of messy, but frankly all aimed at solving the wrong problem. The root cause to every single problem in this space is simple: the OS and the firmware need to coordinate, period. That's a software problem. It's a complicated software problem. And it has to be solved with software engineering, with stuff like interface specifications and division of responsibilities and test suite and conformance tests and all the other boring stuff. And ACPI is, sure, a reasonable language for expressing most of that work. But... no one does the work![1] Vendors make windows run and then ship it, and will occasionally fix bugs reported by critical customers. And that's all you get. Linux comes along later (even new versions of Windows often have crazy workarounds as I understand it) and needs to piece together whatever the firmware is doing ad hoc, because none of those vendors are going to bother with anyone that isn't Microsoft. [1] In the PC world. In the world of integrated hardware things are much better. You can rely on your Mac or your Chromebook or your Galaxy S412 not to have these kinds of bugs, not becuase they use better firmware interface languages (arguably they don't -- I've seen DTS trees for ARM chromebooks!), but because they treat this as a software problem and have the firmware and OS teams work with each other.

mjg59 3y ago
The problem with the PC world is that the firmware and OS teams are not only working for different companies, they're working on different timescales and release cadences. Android devices and Macs are in an entirely different situation here, so the only really comparable example is the Chromebook - and that's a market where if Google doesn't want to support your hardware you don't get to ship it.
- ajross 3y ago
  The point isn't that they're comparable, obviously they aren't. It's that the techniques used to solve the problem (synchronize "timescales and release cadences" in your example) are engineering management things and not technologies. It's true that "Linux vs. Lenovo" doesn't have the same engineering practice tools available. But... evangelizing technological tools like "ACPI" isn't a path to a solution, because... those tools just don't work. Or rather they don't work in the absence of someone addressing the engineering practice problem. They work fine to do what they're designed to do. But what they're designed to do emphatically isn't "Make Lenovo Hardware Work With Linux".

crabbone 3y ago

The only reason I know ACPI exists is because every Linux laptop I ever had always spit a roll of error messages related to ACPI (and usually no support). My understanding is that on top of the inherent problems outlined in the article, there's a more trivial problem of vendors not caring enough to do this right. So, typical for Linux laptops, hybernation and many other forms of power-saving either don't work at all, or are broken (eg. a laptop never wakes up from hybernation, or just the screen never wakes up etc.)

mjg59 3y ago
These days most of these failures are bugs in the Linux drivers, not bugs in the firmware. The Lenovo case I mention in the article is actually unusual in that respect.

somat 3y ago

There are three ACPI stacks. The reference intel one, this is what linux, macos and freebsd uses. The microsoft one. and finally those madlads over at the openbsd project have their own. good for them.

ChickeNES 3y ago
Four: https://github.com/managarm/lai https://github.com/managarm/lai

eismcc 3y ago

I worked on windows kernel team and my first real projects were ACPI 1 and 2 implementation. It's been a while and ACPI was well on its way when i got there, the story at the time was that huge gaps in BIOS were problem and we need to move it into the kernel. There was also a big push from the industry at the same time to use EFI to allow devices to have a pre-os experience (e.g. play DVDs) and not be dependent upon Windows for those. Another memory I have for that time was that powermgmt was a big priority. So i suspect the ability for the OS to do that via ACPI was strategic - I wasn't involved in the decision making.

tenebrisalietum 3y ago

> 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?