Hi,
~ wrote:How much people supports ACPI at least partially and using real mode interrupts (INT 15h?) to at least shut down and turn off the PC?
I parse ACPI tables during boot, and intend to eventually support the "run-time" part of ACPI (but don't yet, and won't for a very long time).
~ wrote:Another question is that, am I right with believing that ACPI is just a "language" interface to perform things like turn off the disks, the screen, the PC, and other things, that could otherwise be performed sending commands and/or values to standard (or nonstandard) peripheral ports?
Yes and no...
Everything that ACPI does could be done by a "motherboard specific" code (not necessarily just "chipset specific" code, as different motherboards may use the same chipset in different ways) that uses I/O ports, PCI configuration space, etc.
ACPI doesn't just do power management though (e.g. setting different power modes), which includes thermal management and noise management (temperature sensors, fan control, etc). It also handles the "off" button, the "sleep" button (if any), and case switches (used to detect if the case is off in some systems that depend on the case being on for proper cooling).
In addition it's used for configuration (the 'C' in "ACPI"). This includes motherboard resources (e.g. programmable PCI IRQ routing, which I/O ports are reserved by the chipset, which I/O ports are used by things like serial ports, parallel ports, floppy controller, PIT, DMA, etc), CPU & APIC detection, NUMA domain detection, hot plug device insertion/removal (for PCI, RAM, CPUs), and other things.
For the "run-time" part of ACPI, the BIOS gives the OS some AML code (ACPI Machine Language) which is byte code for an OOP language. The OS calls routines contained in this AML code.
The ACPI standard does say something about interpretting this code (e.g. like a Java virtual machine), but this isn't the only way. One of the things I'd like to do is have a compiler convert this AML code into native assembly source code, and then combine it with some framework code so that when it's assembled you get a "chipset device driver" for my OS (that is saved to disk and loaded like any other driver after that). This would also allow the source code to be modified (so that the "chipset driver" can be improved), and would allow me to have a large number of pre-compiled binaries that people could download/use. Of course I'm not too sure how practical this approach is yet...
Cheers,
Brendan