Device trees I: Are we having fun yet?

A lot of the arm64 "server" components that people are talking about are not really PC-style servers as we know them from x86 but rather system-on-chip designs more akin to today's embedded 32-bit products. There is no real infrastructure in the kernel to deal with these using ACPI, nor is that likely to get added any time soon.

There is a real danger of people trying to use ACPI on these systems anyway (as shown by some patches posted for X-Gene), which implies that they come up with random out-of-tree and out-of-spec hacks that they cannot rectify before shipping products to end-users. Unlike for dtb files (which can be shipped alongside a kernel), there is not really a backwards-compatible way to replace an ACPI BIOS, so a system like that is either stuck with a custom kernel (i.e. the thing we're all trying to avoid here) or with an ugly per-product workaround (i.e. a board file) in the kernel.

We found out the hard way with DT that it's not really possible to have a stable ABI while simultaneously trying to figure out how to describe things in the first place. ACPI on ARM today is in a worse position than DT on ARM was three years ago when we could sufficiently describe all PowerPC SoCs, and there is no way for ACPI to not be an ABI.