Description
I see from the current state of the spec that building an ACPI table is part of the work that a bootloader should do and that it's considered part of the handoff state to the payload. Asking a few questions around this I learn that this arises from the wish for [some] payloads to support Windows boot (which absolutely requires ACPI) and yet avoid putting some of the very platform specific knowledge into the payload that is more readily handled in the bootloader phase.
I'd like to suggest that making the bootloader do full ACPI support may be an unreasonable burden to address the requirement. An alternate design might be to export the platform specifics from the bootloader and enable the payload to assemble a complete ACPI table if that is necessary for its purposes.
The typical means of export appears from the spec to be HOB list entries. For the kinds of information that would need to end up in an ACPI table it seems more logical to ask the bootloader to provide information in HOBs but to leverage the ACPI individual table entry formats to do that. So imagine a self-describing HOB (see issue #9), that wraps a single table that follows the ACPI defined format for the information that it contains. Multiply that by the number of tables required to convey the platform specific information. Allow the payload to search the HOB list for ACPI-looking things that it can then assemble into a full ACPI table structure.
At the heart of the matter, if there's a perception that the bootloader has to spit out a fully conforming ACPI table structure, RSDT and all, then I believe that's worth re-examining to see if we can avoid the burden of full ACPI compliance in bootloaders that want to support the range of conforming payloads. That particularly applies to bootloaders that are unlikely to be used in the context of payloads that can boot Windows.