ARM, SBSA, UEFI, and ACPI

In truth, it can be hard to say for sure what the SBSA mandates; the standard is currently kept behind a restrictive license, limiting the number of people who have read it. Arnd Bergmann described it this way (in the comments):

Arnd went on to describe the requirements as "extremely reasonable". Olof Johansson, one of the maintainers of the arm-soc kernel tree, was also supportive of the idea:

In short, the SBSA is trying to create a base platform that can be assumed to be present as part of any compliant system. ARM has always lacked that platform, which is part of why supporting ARM systems has traditionally been a messy affair. To the extent that the SBSA succeeds, it will make life easier for kernel developers, hardware manufacturers, and server administrators; it is hard to be upset about that.

Nonetheless, the SBSA announcement has stirred up some heated discussion in the community. But the SBSA is mostly guilty by association; the controversial part of the platform is the firmware requirements, which are not addressed by the SBSA at all. Instead, these requirements will be released as part of a separate specification. The details of that specification are not known, but it has been made clear that it will mandate the use of both UEFI and ACPI on compliant systems.

UEFI is the low-level firmware found on most current PC systems. Like any firmware, UEFI has caused its share of misery, but, for the most part, developers are fine with its use in this context. UEFI works well enough, it has an open-source reference implementation, and supporting UEFI is not hard for the kernel to do. So there is no real opposition to the idea of supporting UEFI on ARM systems.

ACPI (the "Advanced Configuration and Power Interface") is another story. Getting ACPI working solidly on x86 systems was a long and painful process. Its detractors cite a few reasons to believe that it could be just as bad — if not worse — in the ARM world. For example, most ARM system-on-chip (SoC) vendors currently have no experience with ACPI, so they are going to have to come up to speed quickly, repeating lots of mistakes on the way. Each one of those mistakes is likely to find its way into deployed systems, meaning that the kernel would have to support them indefinitely.

There are also concerns about how well an ACPI-based ARM platform will come together. In the PC world, it became clear fairly quickly that the specification only meant so much when it came to hardware support. The real acid test was not compliance with a spec; instead, it was the simple question of "does Windows run on it?" Once Windows worked, firmware authors tended to stop fixing things. That led to numerous situations where the Linux kernel has to carefully do things exactly as Windows does, since that's the only well-tested mode of operation. Windows compatibility is not the most satisfying compliance test out there, but it did result in ACPI implementations converging sufficiently to allow them to be supported in a generic manner.

Windows does not have the same dominating position in the ARM server market; indeed, it's not clear that Windows will be offered on such systems at all. It is certainly possible that, say, Red Hat Enterprise Linux could play a similar role in this space. But it's also possible that vendors will just try to push lots of patches into the kernel to support their specific ACPI implementations. The result could be an incompatible, bug-ridden mess that takes many years to settle out.

Finally, there is the question of whether ACPI is needed at all. ACPI is, in the end, a standardized way to enable the operating system to discover and initialize the system's hardware. But, ACPI critics point out, the ARM architecture already has such a mechanism: device trees. The device tree work is reaching a point where it is reasonably mature; as Olof recently noted in a pull request to Linus:

The developers who have been working on getting this system working well are now asking: why should that work be pushed aside in favor of a PC standard with no history in the ARM world? Among certain developers one can easily pick up a feeling that the kernel should simply refuse ARM ACPI support and mandate the use of device trees on all ARM systems.

In the end, it is hard to see any such thing happening; Linux kernel development has almost always been done in such a way as to favor running on as many systems as possible. And there may well be technical reasons for favoring ACPI on some systems, especially in situations where strict compatibility has to be maintained for years. As Grant Likely put it in a lengthy posting about the upcoming firmware standards, ACPI can make it easier for manufacturers to keep things compatible:

As Grant points out, that abstraction runs counter to the way things have traditionally been done on ARM-based systems; normal practice is to go through a great deal of pin configuration, regulator setup, clock programming, and more just to get things into an operational state. ACPI pushes a lot of that work into the firmware, taking it out of kernel developers' hands. That, perhaps, is where some of the resistance comes from: kernel developers like that control and are reluctant to cede it to firmware authors. It just doesn't feel right if you don't have to establish the right pinmux configuration before anything will work.

Still, ARM servers with ACPI are coming, and the kernel will almost certainly support them. The kernel will also, of course, continue to support device-tree-based systems; the chances of ACPI moving into the embedded world in the near future seem relatively small. After a while, ACPI on ARM will just be another configuration supported by the kernel, and people will be wondering why it was ever controversial. But "a while" may turn out to be a longer period of time than some people expect.