Q: Why does the BRS-I require ACPI _and_ SMBIOS?

[andreiw]

It seems there's overlap between SMBIOS and ACPI. Can you point out why both of these need to present? Why is SMBIOS not redundant with ACPI?

[andreiw]

SMBIOS and ACPI are used for different purposes.

ACPI provides a view of the hardware from a /programmatic/ perspective - what are the interrupt controllers, how to find PCIe segment config space ranges, device MMIO CSRs, etc.

SMBIOS, generally speaking, provides a view of the hardware from an /asset/ perspective (FRUs, versions, physical connectors, slots, etc). If you've ever wondered how an OS knows it's on a Dell server of a certain model, or how the OS knows about firmware versions - this is how. Of course things aren't that clear cut - some OSes (like Windows) won't boot if SMBIOS structures describing DRAM ranges aren't present (this doesn't overlap ACPI, though). Also, SMBIOS is used to discover BMC connectivity on servers via IPMI or Redfish (no overlap with ACPI) and on some architectures, SMBIOS CPU information may be used to detect OS workarounds to be applied.

That's a bit of a long answer. The short answer is that they don't overlap in their functionality. Moreover, both are required for OS-expected functionality on par with industry standard x86 and AArch64 designs. Of course you can "think different" - and many systems in the past have (OpenFirmware/OpenBIOS-based systems, OpenPower, ACE, etc), but a design point for BRS and other related (SoC, server platform) specs has been to stick as close as possible to the dominant ecosystem (x86 and Arm SystemReady, the latter making the same design decision).