>> At least on ACPI systems, one of the big challenges >> has been the breadth of interpretations of the ACPI spec. >> ie. fix one box, break another... > >Mmm. We've seen that a lot. I should probably clarify -- the varied interpretations are by the various OEM's BIOS engineers. Hard to blame them when their job description has been "make it work with windows" and they've had no non-windows ACPI validation test available even if they wanted one -- at least until Linux and FreeBSD etc. started shipping ACPI. >> For configuration, ACPI is somewhat of a catch-all HAL. > >HAL? HAL = Hardware Abstraction Layer >> Its goal is to abstract >> the hardware from the OS. Its goal is not to replace >> standard methods, but to provide a generic interface >> where standard methods do not exist. >> >> eg. PCI knows how to enumerate PCI devices -- >> ACPI is used to enumerate legacy devices. >> >> ACPI-based PCI-hotplug covers non-standard hot-plug controllers, >> but when PCI standardized its hot-plug controller, ACPI isn't >> needed for hot-plug where standard HW has shipped. > >So how does ACPI know which pieces of hardware it needs to >initialise/handle, and which are handled by the PCI-hotplug code? The BIOS writer decides what is abstracted by ACPI by providing ACPI tables to describe it. If it isn't enumerated by the ACPI tables, it is "something else" -- presumably something with a native device driver and native enumeration methods. >> I expect the same thing to happen with CPU, memory, and IO-hotplug -- >> they'll start off non-standard and abstracted by ACPI; and >> then later standard methods may emerge. >> >> >* Driver model implementation. Current focus more on system >> >states (STR, >> >STD). Run-time PM support not handled in driver model? >> >> cpufreq handles run-time PM for processors. >> Sometimes ACPI helps it, sometimes not -- depending >> on the processor and firmware. > >Thought of cpufreq only briefly :> It's my bias, I guess. Processor power management is definitely a big ticket item. While Linux could do better, we're doing good enough that under many conditions other devices consume considerably more power than the processor. eg. the display and its associated hardware. I think that most of the effort spend on Linux power management so far has focused on laptops, and that the consumer electronic devices running on a pair of AAA batteries will have much more extreme power saving requirements. cheers, -Len
