I find ACPI to mostly be useless stuff, and I only have a (huge) driver for it on APIC platforms because I need it to identify IRQs. With older computers with PIC & PIT, I don't load the ACPI driver at all and rely on my own drivers for what hardware is present.Ethin wrote:Uh... Once ACPI 6.4 gets supported by firmware -- which is happening pretty quickly, I'm pretty sure EDK II/OVMF already supports a large majority of it -- you bet that I'll be using it and I'm pretty sure other OSes will switch to it too when supported. It makes AP initialization significantly easier -- no need to mess about with assembly language or any of that stuff, just point the AP at a function to run and boom. I imagine it might also speed up OS startup by small margins too -- it ultimately means that, since most of the work is already done for you, all you have to do is swap out the page tables and your good to go. If I remember right its also architecture independent, unlike previous methods, meaning you can do that same strategy on any architecture that aCPI supports. But I might be wrong on that last point.
The most interesting potential use of ACPI is for handling processor states & boosts, but the ACPI objects exported by many mainboards won't tell you how to do that, and major OSes (Windows & Linux) use their own processor drivers, which probably explains why ACPI doesn't have decent processor objects. So, I also have my own "processor" drivers and ignore ACPI.
So, no, I don't share your enthusiasm for ACPI, and find it to be a rather useless firmware component that too often have serious bugs in the scripts that make simpler ACPI implementations freak out.