OSDev.org

I am learning about the ACPI. It seems the ACPI machine language is provided by the firmware and used by the OS to control the platform hardware. But I don't get the necessity of AML. I posted more details about my question as below. Could someone shed some light? Thanks.

http://stackoverflow.com/questions/4308 ... e-langauge

And what else except a new language would you use?
Everything else (which is not emulated) is dependent of your CPU (architecture) and the ACPI specs aim to be architecture independent.
I dont really understand your arguments, do you really want the devices to hardcode their ACPI stuff in ONE instruction set?
What do you do with x86 vs x86_64? The one CPU can natively execute x86 instructions while the other executes x64 instructions natively.
Both support the same subset of devices.

Your assumption that the hardware is processor-specific is incorrect. For example, ARM platforms can also support ACPI. Hence the need for a processor-independent language.

Hi,

Originally, hardware for "80x86 PC" was cloned from IBM's PC, and this created an effective de-facto standard for hardware to follow. However it didn't take long before manufacturers wanted to add features that didn't previously exist, where there was no (official or de-facto) standard to follow.

This led to a major problem for operating system software (how do you support "non-standard chaos"). Some standards were created for some things (APM, etc) but they didn't really cover everything needed and became out-of-date. ACPI was created to fix this.

Ideally, what was (and still is) needed is standards that allow operating system to detect and use supported features of the motherboard. For example, a "standardised case temperature and fan control" device (with support for detecting how many fans, temperature sensors, etc), or a "standardised CPU speed/power consumption", a "PCI slot IRQ routing for IO APICs" standard, a "hot-plug PCI controller device" standard, etc.

However, ACPI didn't provide useful standards that hardware manufacturers and operating systems can use. Instead, ACPI provided an over-engineered mess (AML) to allow an OS to cope with ACPI's failure to standardise the hardware.

Essentially; we "need" AML now because it's the only viable way for an OS to work-around the "non-standard chaos" problem that ACPI failed to fix.

The problem with providing native code instead of AML is that different operating systems use CPUs in different ways (e.g. native 64-bit 80x86 code in firmware would be useless for an older "32-bit only" OS). AML provides portability between different types of CPUs and between the same CPU/s in different modes.

Also; native code is considered a major security problem (rootkits, etc); and people tend to think an interpreted language mitigates that problem. Of course in practice AML needs far too much access to the underlying hardware and does it in a way that an OS can't check, and there's isn't even a way for an OS to determine if the AML has been maliciously modified before the OS booted. For these reasons AML is still a major security problem despite using interpreted language.


Cheers,

Brendan

Opposite, AML engine is provided by OS, ACPI firmware provides "methods" written in AML, which OS executes.
I believe it's there (instead of native methods) for portability across different CPUs and their used modes of operation.
And yes, it incurs an overhead as every interpreted languauge. When it's about the configuration, it's not that bad though, because it's rare and hardly brings noticeble performance penalty.
One thing I hate about it, that it is irreducible, - there is no way to avoid using it, not breaking the specification. Unlike UEFI EBC, the byte code which is while required to have been implemented by conformant implementations, is not required to write UEFI drivers in it. You may totally avoid it writing native drivers. It's especially relevant for SoC-based solutions where 90% controllers sit on one chip, so you cannot bother with "portabilty" issues.

Brendan correctly stated ACPI is a mess.

Linus Torvalds has the best quotes regarding ACPI:
"The fact that ACPI was designed by a group of monkeys high on LSD, and is some of the worst designs in the industry obviously makes running it at any point pretty damn ugly."
"Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce."
"EFI is this other Intel brain-damage (the first one being ACPI).”

It would have been fairly simple to design a standard PCI device for motherboard power button, temperature measurements and fan controls. But no, instead of that we have the disaster of ACPI and AML.

PCI IRQ routing is terrible, Intel failed miserably by making it "implementation specific". PCI_22.pdf has "Implementation Note: Interrupt Routing". Intel should have made it MANDATORY for the IBM / PC AT that IRQW - IRQZ is always mapped to 8259 PIC IRQs 11,10,9,7. Intel should have mandated that ISA ATA is "remapped" via SMM, so it can be routed to any PCI device.
Intel should have made it mandatory for the IO APIC to follow a similar scheme. E.g. if IO APIC has 24 pins, then it supports 6 PCI device numbers x 4 interrupt pins. If there are more than 6 PCI device numbers, device nbr 6 and 0 overlap etc.
That is much simpler and more reliable than the mess of ACPI/AML.

PCI hot plug should have been managed by adding extra standard functionality to the IO APIC. Instead we have the disaster of ACPI / AML.

I am extremely disappointed ARM systems have also decided to implement the ACPI AML brain damage.

To be completely honest, yes ACPI is a design disaster, but kudos to intel recognizing this issue and giving us ACPICA. I mean it really takes most of the **** out of having to deal with ACPI. The only issue is the code size of ACPICA.

And much less reliable and forward compatible. How do you enumerate PCI root complexes? We already have NUMA systems with multiple PCI roots. Plus there are devices that fundamentally cannot be part of the PCI, for example VT-d and persistent memory DIMMs.

It would also mean that we would never be able to get rid of stuff like ATA or the other legacy chips like the PIT, PIC, I/O APIC and RTC. ACPI allows us to get rid of them on specialized hardware (e.g. SoCs, server or HPC hardware). In the far future it could even allow us to get rid of them on desktops.

I agree that ACPI is ugly and a mess, especially the AML power management and device configuration parts. However I acknowledge that it could not have been replaced by simple static rules. You need some mechansim to enumerate and relocate devices on the system bus.

EDIT: It seems getting rid of the legacy hardware is already being done in commodity hardware.

Hi,



For PCI; I think MSI should've become mandatory far sooner.



No it doesn't. For legacy devices you only really need a "present or not" flag in some kind of table (e.g. ACPI's "FADT") and don't need AML.



Yes, you'd need/want a mechanism that allows you to determine the right driver for a "motherboard fan controller" or "motherboard LCD screen backlight controller" or ... This is entirely possible.

Every single thing that AML is used for can be done with static tables and/or standardised hardware (with some kind of enumeration). Sure there'd be a few minor "engineering problems" to work around, but it's trivial to find solutions to all of them.


Cheers,

Brendan

Torvalds is good at being a jealous dickhead, not as good at being able to bring something better than UEFI or ACPI or anything. More fun seeing them accepting that "LSD high monkeys made" standards into their messy calque of unix.

Like most of the "warts" of the x86 PC architecture, this came about as a result of the "1987-1997 anarchy" when there was no clear "authority" in charge of defining and developing the PC and many competing standards and technologies.

The "standardised hardware" method was tried. That's why we still have (versions of) thoroughly obsolete 35-year-old devices in our "modern" PC.

Tying ACPI (or whatever it's alternate reality equivalent would have been called) irrevocably to PCI would have been a mistake; ACPI was originally created in 1996, when PCI was only 4 years old and still not universally accepted. While PCI was certainly extremely popular, Intel didn't have the kind of control over the PC platform that they have now and had no way to know that PCI wouldn't end up going the way of EISA, MCA or VLB. If ACPI was tied to PCI, it wouldn't survive if PCI didn't.

With hindsight, we now know that PCI did become the "standard" PC bus and that Intel (working with Microsoft) has effectively become the authority on the x86 PC architecture, so much of the flexibility built into ACPI now seems unnecessary and misguided. That wasn't obvious at the time.

AML is absolutely awful and over-complicated, over-engineered and a theoretical security risk (although if the system firmware is compromised, so is everything else; it's a threat not worth worrying about), but it certainly made a lot more sense at the time. Creating something that's supposed to deal with the inherently uncertain future is hard, there's certainly nothing "trivial" about it.

The fact that ACPI (including AML) has provided flexible enough to be used on non-x86 platforms and new, incompatible processor modes is testament to how well it fulfilled its design goals. It's not "nice", not "good", but it works.

Hi,



I don't think anyone suggested tying anything irrevocably to PCI. I only suggested "some kind of enumeration mechanism", which could be as simple as an static ACPI table that says things like (e.g.) "there's a fan and temperature controller at <location> that complies with <hardware_standard>"; combined with competent design of those hardware standards (e.g. including a way to identify fans and temperature sensors in the relevant hardware standard, in the same way that USB controllers have a standard way to determine the number of USB ports, or HPET has a standard way to determine capabilities, etc); such that an OS can have a small number of generic drivers without any AML nonsense needed (and without the risk of relying on potentially buggy firmware, etc).



From my perspective at the time (which was relatively common in the late 1990s), the original design goal was to ensure that it's extremely difficult (due to both complexity and the "OS name" problem) for alternative OSs (e.g. Linux, FreeBSD, etc) to compete against Windows. If it wasn't for Intel paying a team of developers for about 10 years to create ACPICA it would have succeeded.


Cheers,

Brendan

The problem with that solution is that while the table tells you what hardware is available, you still need to have a driver for each possible device. If someone comes out with a new device (e.g. a new kind of fan contoller), you can't do anything with it until the OS has a new driver, even if it's a new "standard" device.

We've seen this happen with USB (OHCI, UHCI, EHCI, xHCI), but at least with those the worst that happens is that the USB devices connected to the new controller don't work. With power management, having "partial" control isn't safe; not being able to control certain fans or monitor certain temperatures could easily lead to hardware damage (or in reasonably well-designed hardware, the system powering off without warning when it overheats). Personally, I believe any piece of hardware that can be physically damaged by software means is inherently defective and should be returned to place of purchase immediately for refund, but unfortunately such garbage exists and isn't even extremely rare.

If the system can't boot up and remain stable (e.g. because some of the fans cooling essential hardware don't work), how can the user install the necessary updates/drivers? While it's much easier now with readily available high-speed Internet, in the time when ACPI was designed, it wasn't reasonable to require a new OS install disk to be issued every time a new piece of hardware was released.

Of course, ACPI doesn't always work as well as it should and systems do still sometimes overheat (or sound like a jet taking off and wear out their fan motors due to "fail-safe mode"; max-speed fans running at all times), but for the most part, they'll work well-enough to get an OS and drivers installed.



I prefer not to assign to malice what can adequately be explained by incompetence and naivety. While there are plenty of examples of systems shipping with obviously broken and untested non-Windows AML, I see this more as incompetence by vendors who are too cheap to care about non-mainstream platforms, rather than a deliberate attempt to stifle alternative operating systems. Intel were obviously pretty naive to not expect this to happen, but I expect there were pressing reasons for it at the time (e.g. Windows 9x and NT having different ACPI compatibility levels).

Still, there were plenty of distasteful practices by software and hardware vendors at the time, so you're right to be suspicious.

Hi,



Sure, except it's much much easier to provide a few generic drivers (including a few new drivers very rarely) than it is to provide a massive pile of bloat that has to be constantly maintained/updated every time a new ACPI spec is released and every time a new version of Windows (that your OS has to pretend to be and work exactly like) is released.



The only reason EHCI and xHCI exist is to support higher speeds. Things like (e.g.) a "fan and temperature sensor controller" isn't going to have to be changed to increase "temperature sensor bandwidth" every ~5 years.



For power management; you want each PCI device driver to manage the power for its PCI device (and anything attached to it) independently (like we already do because it has nothing to do with ACPI); and you want all the logic for CPUs speed, CPU temperature and CPU fan in one place (near the scheduler); and the logic for case temperature and fan/s in another completely different place; and you want all of these separate systems to operate in an entirely independent manner (hopefully with fail-safes, and hopefully with semi-intelligent control where you set (e.g.) a fan speed for each temperature range once instead of software having to do constant/periodic micro-management).



Obviously it'd be designed to "work" without any drivers at all (just without the OS being able to control things, and probably with things like "fans stuck at max. speed" and "no notification when laptop battery almost flat", etc).


Cheers,

Brendan

While I don't disagree with the first part of that sentence, as far as I can tell, the second half is a non-sequitur. What influence do you think he could possibly have on a hardware standard, especially one that was already being mooted by PC manufacturers as early as 1996, well before Linux had made any real impact (not that it ever really did, and I say that as someone who is typing this on a Linux box, but anyway)?

Even Microsoft, who were in the original ACPI consortium, probably had relatively little influence on the design, mostly of the "please don't break the software we've already written" variety. I doubt that the designers of UEFI seriously took any OS other than Windows into account, either, and even considering Windows itself was mainly because Microsoft was trying to get them to make it so no other OS could boot from it - they did resist that, but compromised by adding a system lock-out which hardware vendors could enable on their systems. My understanding is that a lot of systems set that by default, but allow it to be reset with the warning that it voids the warranty.

(Mind you, there was a legitimate argument for it on the basis of security, in order to prevent rootkits from installing themselves. However, the real motive was cost-cutting; the hardware manufacturers mainly saw it as a way to narrow the scope of their support calls by making it so only the operating systems they were willing to support could be used, regardless of which OS that happened to be.)

I agree that Torvalds' comments were sour grapes, but they were borne out of frustration with something he had no say in, not because he thought he could do better himself (well, maybe he did think that, too, but that hardly matters to him or anyone else).