Thank you for providing detailed information about Thermal Management. I downloaded ACPI version 2 spec and latest version 6.5 spec; I didn't read every single word but have made some observations for you.
ACPI Version 6.5 has section: 11.5 Native OS Device Driver Thermal Interfaces This section didn't appear in version 2. Maybe the light bulb has finally turned on...... Operating System should be using direct hardware interface instead of dubious convoluted "ACPI Machine Language".
You appear to claim ACPI is "extensible". However there is simple proof that isn't true. In ACPI version 2 section 12.3 Thermal Objects, it lists 13 different types of objects. ACPI version 6.5 section 11.4 Thermal Objects lists 26 different types of objects. Clearly, ACPI version 2 was NOT "extensible"; they had to make major changes to it in later versions. If ACPI was truly "extensible", an Operating System written in 2002 to version 2 of spec would still have 100% compatibility with ACPI today. That is not the case so clearly the "extensible" claim is false.
Now, for writing a not bloated Thermal Management specifiction...
In ideal world, the Operating System has native drivers for all hardware (e.g. a GPU). The OS driver knows how to read the GPU temperature sensor. The OS driver knows the temp the GPU will turn on it's fan. The OS driver knows critical temp for the GPU where it will shutdown automatically. It's not the job of Thermal Management specification to provide this information.
I would expect a GPU operates in lower power mode by default, and only goes into high power mode when Operating System drivers do necessary magic. This should be the same for ALL devices. They should operate in lower power mode until the Operating System activates higher performance modes. PCI has a generic power management specification, so I believe even "unknown" PCI devices can be put in low power mode.
For x86-64 CPUs, they should have a standard method for reading the temperature sensor. They should have standard Model Specific Register to inform the OS what temperature the fan will be required, and what temp will force hardware shutdown. They should have standard MSRs describing the power states S0 - S3. They should have standard hardware method for putting CPU into different power states. Let me guess, Intel and AMD do it differently.....
Section 11.1 of ACPI 6.5 spec has nice diagram of a "Thermal Zone", it shows what is required for thermal management.
"Thermal Zone-wide active cooling device" would be something like cpu or case fan, connected directly to northbridge chipset. One problem is I don't think there is standard hardware interface for this. Instead of bloated ACPI, a standard hardware interface for "motherboard fans" should be developed. All chipsets should follow this standard.
"Thermal Zone-wide temperature sensor" is similar to above. Instead of bloated ACPI, a standard hardware interface for "motherboard temperature sensors" should be developed.
The final requirement of a "not bloated" Thermal Management specification is specify how components interact e.g. where they are located in respect to each other.
So the spec does require a list of Thermal Zones (probably usually 1). Each zone has a list of Devices (I think _TZD in ACPI lingo). For each device in the list, it has x,y,z coordinates to specify its location relative to everything else. As stated above, the Operating System has native driver to understand the device details, or OS has generic (PCI etc) driver to put unknown device into low power mode.
Voila.... thermal management done with less bloat than ACPI. And without using ACPI Machine Language.
Repeating myself.... ACPI is bloated highy complicated specification (e.g. AML) that causes problems. The only excuse for ACPI is a lack of hardware standardisation, consequently forcing a very generic indirect specification.
no subject
ACPI Version 6.5 has section: 11.5 Native OS Device Driver Thermal Interfaces
This section didn't appear in version 2.
Maybe the light bulb has finally turned on...... Operating System should be using direct hardware interface instead of dubious convoluted "ACPI Machine Language".
You appear to claim ACPI is "extensible". However there is simple proof that isn't true. In ACPI version 2 section 12.3 Thermal Objects, it lists 13 different types of objects. ACPI version 6.5 section 11.4 Thermal Objects lists 26 different types of objects. Clearly, ACPI version 2 was NOT "extensible"; they had to make major changes to it in later versions. If ACPI was truly "extensible", an Operating System written in 2002 to version 2 of spec would still have 100% compatibility with ACPI today. That is not the case so clearly the "extensible" claim is false.
Now, for writing a not bloated Thermal Management specifiction...
In ideal world, the Operating System has native drivers for all hardware (e.g. a GPU). The OS driver knows how to read the GPU temperature sensor. The OS driver knows the temp the GPU will turn on it's fan. The OS driver knows critical temp for the GPU where it will shutdown automatically. It's not the job of Thermal Management specification to provide this information.
I would expect a GPU operates in lower power mode by default, and only goes into high power mode when Operating System drivers do necessary magic.
This should be the same for ALL devices. They should operate in lower power mode until the Operating System activates higher performance modes.
PCI has a generic power management specification, so I believe even "unknown" PCI devices can be put in low power mode.
For x86-64 CPUs, they should have a standard method for reading the temperature sensor. They should have standard Model Specific Register to inform the OS what temperature the fan will be required, and what temp will force hardware shutdown. They should have standard MSRs describing the power states S0 - S3. They should have standard hardware method for putting CPU into different power states. Let me guess, Intel and AMD do it differently.....
Section 11.1 of ACPI 6.5 spec has nice diagram of a "Thermal Zone", it shows what is required for thermal management.
"Thermal Zone-wide active cooling device" would be something like cpu or case fan, connected directly to northbridge chipset. One problem is I don't think there is standard hardware interface for this. Instead of bloated ACPI, a standard hardware interface for "motherboard fans" should be developed. All chipsets should follow this standard.
"Thermal Zone-wide temperature sensor" is similar to above. Instead of bloated ACPI, a standard hardware interface for "motherboard temperature sensors" should be developed.
The final requirement of a "not bloated" Thermal Management specification is specify how components interact e.g. where they are located in respect to each other.
So the spec does require a list of Thermal Zones (probably usually 1). Each zone has a list of Devices (I think _TZD in ACPI lingo). For each device in the list, it has x,y,z coordinates to specify its location relative to everything else. As stated above, the Operating System has native driver to understand the device details, or OS has generic (PCI etc) driver to put unknown device into low power mode.
Voila.... thermal management done with less bloat than ACPI. And without using ACPI Machine Language.
Repeating myself.... ACPI is bloated highy complicated specification (e.g. AML) that causes problems. The only excuse for ACPI is a lack of hardware standardisation, consequently forcing a very generic indirect specification.
Any "praise" of ACPI is misguided.