Comment by tux3
1 year 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.
There already is an eBPF for Windows, it's even Microsoft's own project https://github.com/microsoft/ebpf-for-windows
Ahh. Just as the prophecy foretold.
Unlikely. ACPI is made by Wintel vendors, so Windows will get support for the fancy new things and Linux will lag behind until the new thing is documented or reverse engineered.
ACPI is standardized via a specification. It's quite easy for non windows operating systems to support ACPI. I can't say the same for device tree as that requires reading Linux source.
Lots of things are available in a specification. HTML, for instance. Just being an open specification is insufficient when there's a superdominant implementation. At that point, that implementation is the specification.
In HTML, it was Internet Explorer for a long time, now it's Chrome/Chromium.
In ACPI, it's Windows. In fact, Linux pretends to be Windows because anything else is a shipwreck graveyard of disappointment and untested code.
https://askubuntu.com/questions/28848/what-does-the-kernel-b...
Also, see the whole necessity of patching your DSDT (Windows users: "The what?" Linux users: nodding sadly) https://wiki.archlinux.org/title/DSDT
Modern computers are sufficiently complicated that they really only support one OS. And of course, those are almost entirely Windows computers. Buy a computer with Linux preinstalled, with support, if you want to avoid having to care about things like this (or having a computer that never works quite right (e.g. doesn't reliably suspend or the fans are running wrong)).
3 replies →
That specification is a monster. "quite easy to support" is not a good description of the situation.
1 reply →
My understanding from ~10 years ago is:
There is a specification
Windows ACPI implementation is buggy
Hardware manufacturers implement Microsoft's implementation bug for bug
Everyone has to reverse engineer Microsoft's implementation because the standard isn't enough
6 replies →
The lack of support usually comes from the other side: the h/w vendors aren't testing with anything but Windows.
I'm yet to see a Linux laptop where ACPI wasn't broken at least for one device (the most likely suspects are the components that aren't typically used in servers, s.a. webcams or wifi modems).
> 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-cb...
[2] https://www.theiphonewiki.com/wiki/DeviceTree
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.
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.
2 replies →
BPF doesn't really make sense here. It can't fully specify the kinds of computation an AML replacement would need since BPF is guaranteed to terminate (it's not Turing complete).
For this use case (hardware configuration), that might actually be desirable?
I don't think you'll get uptake removing constructs like
since AML is less a hardware description format and more a driver binary format.
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.
Why bother with bespoke bytecode when we have a high quality, standard ISA?
RISC-V's base RV64I has 47 instructions. Legacy ISAs can simply emulate these 47 instructions.
Bytecode is presumably chosen to minimize the program length, while the RISC-V is at the opposite end of verbosity for representing a program.
You may be one of those who believe that RISC-V is a high-quality ISA, but this is not an universal opinion and it is a belief that is typically shared only by those who have been exposed to few or no other ISAs.
In the context of something like ACPI, I would be worried by the use of something like the RISC-V ISA, because this is an ISA very inappropriate for writing safe programs. Even something as trivial as checking for integer overflow is extremely complicated in comparison with any truly high-quality ISA.
For example, Open Firmware specification used a flavour of Forth for its bytecode.
How patronising. Can you give an example of an ISA that is higher quality than RISC-V?
8 replies →
What makes you think RISC-V is a good fit for device configuration?
Simplicity, lack of flags or arithmetic exceptions, as well as clear ABI and environment call mechanism.
Hardware access could be clearly gated through ecalls, and the mechanisms for this could exist as a standard extension in the SBI interface.