3 ms·

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

by 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".
  - mjg59 3y ago
    My point is that focusing on tight integration between OS teams and the underlying platform is a great way to develop a device that only runs one operating system and a terrible way to develop a device that's supposed to be part of an open ecosystem. ACPI is the least bad way we currently have to solve the latter problem. It doesn't guarantee that a Lenovo will work with Linux, but in the absence of an explicit development program it gives it a fighting chance.
    - stonogo 3y ago
      ACPI is only the "least bad way" because vendors don't release sufficient information to do anything else. Microsoft and Intel just specify progressively more convoluted nonsense, require OEMs to pass spec or they can't buy chips or Windows licenses, and nothing ever gets any better until some dedicated hobbyist reverse-engineers whatever ridiculous software most recently won someone a promotion. You don't need tight integration between hardware and OS teams, you just need any transparency from the hardware side, and we don't get that any more. The least bad way would be for the people building the computers to document them sufficiently well for software engineers to support them, but part of the PC market mass hallucination is that every OEM's particular way of doing exactly the same shit is some magic secret recipe, and letting the competition see the herbs and spices would be the end of the world. Meanwhile the entire market segment derives from the original IBM PC being designed by adults with sufficient discipline that the resulting product consituted a platform. All we've seen since is various scavengers fighting ridiculous turf wars over the ruins of interoperability. It's an industry-wide case of learned helplessness. It's a morass that is holding back innovation, and "at least the septic tank is only waist deep" isn't really much of a contribution toward solving anything. I wish there were for personal computers what Oxide is for datacenter engineering, but wishing isn't much of a contribution either.
      - mjg59 3y ago
        Yes, the world would be better with better documentation. But that doesn't solve the "How do I ship a new platform that works with existing operating systems" problem. ACPI provides an abstraction that allows some amount of divergent platform behaviour while retaining compatibility with existing operating systems. Even if all vendors released docs (which isn't terribly realistic), we'd still end up having to write new drivers for them, getting those merged upstream, and then deal with the lag between that and Linux distributions shipping them to end users.
p_l 3y ago
The reality is that for highly integrated devices, you just ship a bunch of hacks, sometimes because you forgot to follow the spec and it was faster to patch a line in kernel than patch the firmware (Hello, intel mac broken ACPI tables!). A kernel driver for a phone component might have hardcoded set of quirks selected by string from device tree. In the world of PCs, the reason Linux emulates Windows in terms of ACPI is because Microsoft not only is a big vendor - all those "designed for windows" labels on computers actually required passing test suites etc. Microsoft also publishes add-on specifications for things that are underspecced in ACPI - for example the ACPI spec does specify how to make an interface for backlight control. But it does not tell you the ranges that the OS and said interface have to support. Microsoft provides such description, that for example if OS responds with _OSI(Windows2003) then the supported ranges will be 0-5 (purely imagined example), but if it also responds _OSI(Windows2007) then the supported values can be 0-15, etc. This is also why firmware situation on ARM is so shitty - vendors aren't forced to do the work, so they don't. With Windows, the vendor is external and it's pretty rare to avoid implementing things right (one example is Qualcomm fucking up Windows-on-ARM interfaces somewhat impressively and fixing it by injected drivers)
- ajross 3y ago
  > The reality is that for highly integrated devices, you just ship a bunch of hacks, That's true, but only in the specious sense that all integrated software is "a bunch of hacks". Fixing glitches due to misunderstandings between an API consumer and an API provider is something we all do, every day. And the essence of the problem is no different whether the technology is a Javascript app framework or a NVMe firmware driver. I mean, sure, it's better to make sure that the NVMe firmware driver (picking on that because it was an example in the linked article) and the OS have a clean specification for interaction. And sometimes they do! But it's likewise important that everyone write appropriately idiomatic React code too, and we don't demand[1] a whole new technology idiom to prevent front end developers from doing dumb stuff. The solution is about engineering practice and not technology, basically. ACPI isn't going to solve that, for the reason that ACPI didn't create the problem. It's not ACPI's problem to solve. [1] Well, people kinda do, actually. Abstraction disease is another problem.
lmm 3y ago
> And ACPI is, sure, a reasonable language for expressing most of that work. But... no one does the work![1] Maybe. Or maybe the "work doesn't get done" in part because that interface language is simultaneously overengineered and underspecified, and people who start out with the best of intentions end up drowning under a pile of incomprehensible ACPI docs and copy and pasting whatever junk seems to make Windows handle it ok because that's the only way out of the nightmare.

by ajross 3y ago

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".
- mjg59 3y ago
  My point is that focusing on tight integration between OS teams and the underlying platform is a great way to develop a device that only runs one operating system and a terrible way to develop a device that's supposed to be part of an open ecosystem. ACPI is the least bad way we currently have to solve the latter problem. It doesn't guarantee that a Lenovo will work with Linux, but in the absence of an explicit development program it gives it a fighting chance.
  - stonogo 3y ago
    ACPI is only the "least bad way" because vendors don't release sufficient information to do anything else. Microsoft and Intel just specify progressively more convoluted nonsense, require OEMs to pass spec or they can't buy chips or Windows licenses, and nothing ever gets any better until some dedicated hobbyist reverse-engineers whatever ridiculous software most recently won someone a promotion. You don't need tight integration between hardware and OS teams, you just need any transparency from the hardware side, and we don't get that any more. The least bad way would be for the people building the computers to document them sufficiently well for software engineers to support them, but part of the PC market mass hallucination is that every OEM's particular way of doing exactly the same shit is some magic secret recipe, and letting the competition see the herbs and spices would be the end of the world. Meanwhile the entire market segment derives from the original IBM PC being designed by adults with sufficient discipline that the resulting product consituted a platform. All we've seen since is various scavengers fighting ridiculous turf wars over the ruins of interoperability. It's an industry-wide case of learned helplessness. It's a morass that is holding back innovation, and "at least the septic tank is only waist deep" isn't really much of a contribution toward solving anything. I wish there were for personal computers what Oxide is for datacenter engineering, but wishing isn't much of a contribution either.
    - mjg59 3y ago
      Yes, the world would be better with better documentation. But that doesn't solve the "How do I ship a new platform that works with existing operating systems" problem. ACPI provides an abstraction that allows some amount of divergent platform behaviour while retaining compatibility with existing operating systems. Even if all vendors released docs (which isn't terribly realistic), we'd still end up having to write new drivers for them, getting those merged upstream, and then deal with the lag between that and Linux distributions shipping them to end users.

p_l 3y ago

The reality is that for highly integrated devices, you just ship a bunch of hacks, sometimes because you forgot to follow the spec and it was faster to patch a line in kernel than patch the firmware (Hello, intel mac broken ACPI tables!). A kernel driver for a phone component might have hardcoded set of quirks selected by string from device tree. In the world of PCs, the reason Linux emulates Windows in terms of ACPI is because Microsoft not only is a big vendor - all those "designed for windows" labels on computers actually required passing test suites etc. Microsoft also publishes add-on specifications for things that are underspecced in ACPI - for example the ACPI spec does specify how to make an interface for backlight control. But it does not tell you the ranges that the OS and said interface have to support. Microsoft provides such description, that for example if OS responds with _OSI(Windows2003) then the supported ranges will be 0-5 (purely imagined example), but if it also responds _OSI(Windows2007) then the supported values can be 0-15, etc. This is also why firmware situation on ARM is so shitty - vendors aren't forced to do the work, so they don't. With Windows, the vendor is external and it's pretty rare to avoid implementing things right (one example is Qualcomm fucking up Windows-on-ARM interfaces somewhat impressively and fixing it by injected drivers)

ajross 3y ago
> The reality is that for highly integrated devices, you just ship a bunch of hacks, That's true, but only in the specious sense that all integrated software is "a bunch of hacks". Fixing glitches due to misunderstandings between an API consumer and an API provider is something we all do, every day. And the essence of the problem is no different whether the technology is a Javascript app framework or a NVMe firmware driver. I mean, sure, it's better to make sure that the NVMe firmware driver (picking on that because it was an example in the linked article) and the OS have a clean specification for interaction. And sometimes they do! But it's likewise important that everyone write appropriately idiomatic React code too, and we don't demand[1] a whole new technology idiom to prevent front end developers from doing dumb stuff. The solution is about engineering practice and not technology, basically. ACPI isn't going to solve that, for the reason that ACPI didn't create the problem. It's not ACPI's problem to solve. [1] Well, people kinda do, actually. Abstraction disease is another problem.

lmm 3y ago

> And ACPI is, sure, a reasonable language for expressing most of that work. But... no one does the work![1] Maybe. Or maybe the "work doesn't get done" in part because that interface language is simultaneously overengineered and underspecified, and people who start out with the best of intentions end up drowning under a pile of incomprehensible ACPI docs and copy and pasting whatever junk seems to make Windows handle it ok because that's the only way out of the nightmare.