Does UEFI replace standards like SMBIOS and ACPI?
I always wondered, as a developer with little experience in what goes on behind the OS, why is firmware such a mess. I'm trying to understand at least where the pieces fit. Is UEFI trying to replace all these previous standards for interacting with the firmware or it incorporates them?
No.
UEFI is a different standard than ACPI and SMBIOS.
UEFI was created with the intent to standardize the interface between the OS and the firmware for the purpose of booting the OS.
When booting, the OS is in the peculiar position of needing to talk to the hardware to be able to load the rest of itself, but it needs the rest of itself (drivers) to talk to the hardware.
The firmware services were provided to give the OS minimal support for talking to the hardware.
But these services were never standardized properly, they were born out of conventions and legacy (for example, 16-bit real mode BIOS interfaces, and ancient C/H/S drive geometry with various ways to work around disk-size limits, and no standard partition or other clear place to put more than 1 sector (512 bytes) of bootloader code).
UEFI modernizes the interface. Quoting:
Built on existing investment. Where possible, the specification avoids redefining interfaces and structures in areas where existing industry specifications provide adequate coverage. For example, the ACPI specification provides the OS with all the information necessary to discover and configure platform resources. Again, this philosophical choice for the design of the specification is intended to keep barriers to its adoption as low as possible.
Section 1.3 (Goals) of the UEFI specifications has a list of goals for UEFI.
ACPI is a standardized interface to pass information (in the form of tables and bytecode) from the firmware to the OS.
Some hardware is not discoverable and the OS could only support it by including a big list of presence-tests and drivers.
But the firmware knows the hardware because it was compiled with a set of switches, set by a human, that match the hardware.
ACPI is the way the firmware passes this information to the OS. The actual specification itself is more complex because it includes a whole abstract namespace with executable methods and various concepts.
But the idea is simple: inform the OS about the hardware.
SMBIOS does partly overlap with ACPI; they are two standards designed by different organizations.
SMBIOS is much simpler than ACPI or UEFI: it limits itself to simply reporting a set of static information to the OS.
While ACPI provides the OS with information to manage the hardware, the SMBIOS specification mostly gives human-readable information (e.g. firmware versions or in which physical PCI slot a device is installed).
Note that the SM in SMBIOS means System Management and it collides with the SM in SMM (System Management Mode).
In fact, by SMBIOS I wrongly assumed you meant the part of the firmware run in SMM (which I guess is called the same).
SMM is basically an event-driven mechanism to call back into the firmware transparently to the OS.
This functionality is used to implement some hardware features in software (i.e. emulate them, like legacy PS2 support or fTPM), to respond to critical events that the OS cannot be trusted to handle (errors or thermal failure) or to transparently trick the OS for management purposes (e.g. reboot, Key-Video-Mouse services and so on).
Keep in mind that these specifications were made by different people at different times. (But UEFI and ACPI are currently maintained by the same organization.)
Once a standard is picked up by enough software (or import enough software companies) then it stays forever.
You are probably already aware of this picture:
(note that the "EFI OS Loader" is actually part of the OS, not UEFI. It's loaded by the firmware, and uses UEFI calls to load the rest of the OS.)
You can see that the UEFI is side by side with ACPI and the SMBIOS.