Linus Torvalds announced the first Linux 4.1 release candidate kernel saying, “no earth-shattering new features come to mind, even if initial support for ACPI on arm64 looks funny. Depending on what you care about, your notion of ‘big new feature’ may differ from mine, of course. There’s a lot of work all over and it might just make a big difference to your use cases.” New features in Linux 4.1 include the new ‘simple persistent memory’ driver (which enhances support for Non-Volatile Memory devices), support for single user-only systems where support for multiple users is configured out (for very small embedded systems that don’t have resources and need to save 25 KB of RAM), and support for filesystem-level encryption in ext4. The subsequent RCs add a few fixes, including one “so old that I almost thought if it’s been broken since 2011, and you only noticed now, maybe it could have waited.”
Kdbus?ACPI on 64-bit ARM systems
One of the new features in Linux 4.1 is support for ACPI (Advanced Configuration and Power Interface) on (mostly server) 64-bit ARM systems. ACPI enables the discovery of devices and system properties not expressed through self-enumerating peripheral buses and technologies. For example, when you attach a USB dongle or a PCIe adapter card to your laptop or desktop, that system can perform an automated discovery of its properties as an intrinsic capability of the USB and PCIe buses. But how does the same system know about the presence of the USB and PCIe buses? ACPI aims to answer this question and its requirement in the ARM Server Base Boot Requirements (SBBR) is addressed by Linux 4.1 (full disclaimer: this author was a coauthor of the ARM SBBR specification).
ACPI provides the glue that connects platform devices, and provides information about the platform that varies from one manufacturer to another. It does this using tables – data structures having a four-character name and providing certain information specific to the table type in question. Certain tables must be provided, while others are optional. When the operating system boots, UEFI (the system firmware) passes a RSDP (Root System Description Pointer) to the operating system as part of the process. This RSDP points to the XSDT (Extended System Description Table), which contains pointers to others. Some are required, such as the MADT and the DSDT (Differentiated System Description Table), while others, like the MCFG (provides the glue to discover the PCIe bus), may not be provided on systems that don’t need a feature (PCIe).
ACPI has long existed on Intel architectures (contemporary 64-bit ‘x86’ and the older Itanium) but it is new elsewhere, and its adoption by emerging ARM server systems is not without critics. They would cite that a very similar functionality is provided by Device Tree, which is a specification derived from Open Firmware’s similar system description tables. Device Trees have the kind of data present in ACPI’s DSDT, including entries for each platform device and its memory location. There are several key differences between ACPI and Device Tree, however. Firstly, ACPI provides AML (ACPI Machine Language), which enables manufacturers to supply small embedded code routines that the OS can interpret to enable some functionality without a specific driver. While AML is hated by some in the Linux kernel community, it is one of the evils that has enabled mass market adoption of x86-based laptops that work out of the box without special drivers.
Secondly, ACPI is supported by an industry standardisation consortium (the UEFI Forum). UEFI Forum provides neutral governance of the ACPI (and UEFI) specifications and manages changes over time. Device Tree is flexible and its core is covered by an obsolete standard, but the bindings that describe the properties provided by vendor Device Trees aren’t controlled by a central authority. The closest thing to a standard for DT is the Linux kernel Documentation directory, which changes over time and has led to many incompatible breakages. That’s acceptable for mobile phones that are built as a vertical stack of kernel and OS, but not for servers that run different releases of operating systemsoftware and kernel versions over time.
Finally, the use of ACPI on ARM is mostly constrained to server class systems, where vendors are familiar with ACPI. They know how to provide ACPI tables for server systems that support a plurality of operating systems. Time will tell how well the ARM server ecosystem shapes up. In the interim, Linux distros include ACPI support in their 4.1 release candidate kernel builds, providing support for such first-generation 64-bit ARM servers.