3 ms·

Devicetree is in effect doing the same thing as ACPI tables. It actually usually is passed into the kernel by the bootloader. The main thing that prevents havin

Devicetree is in effect doing the same thing as ACPI tables. It actually usually is passed into the kernel by the bootloader. The main thing that prevents having one vanilla kernel that works on most ARM SBCs (where the vendor only provides a devicetree like they provide ACPI tables) is the fact that most of them don't have full upstream support so you need to run a custom kernel anyway. (Secondly, because it tends to be used primarily on systems where you are building your own patched kernel anyway, most devicetrees are not so much a generic description of a device as initialisation data for a specific driver)

surajrmal 3y ago
Lack of peripheral standardization is a big piece too. You're not going to include every possible arm peripheral driver in your image. There are far fewer drivers necessary to include on PC by comparison (and they are often less space constrained anyways so including those drivers isn't a big deal).
- rcxdude 3y ago
  It's not much different. PC linux distros already bundle basically all the device drivers for not just the PC box itself but all the peripherals you might plug into it. The ARM ecosystem if anything has fewer peripherals, it's just not upstream.
AshamedCaptain 3y ago
There is also the fact that ACPI allows embedding executable code, which in effect allows system vendors to hide proprietary drivers on it. E.g. HID stuff such as brightness control or keys which do not (generally) need any kernel code to work and are generally impossible to define with DT unless they are simple single-purpose GPIO pins.
- trelane 3y ago
  ACPI is executable code. "Much of the firmware ACPI functionality is provided in bytecode of ACPI Machine Language (AML), a Turing-complete, domain-specific low-level language, stored in the ACPI tables.[7] To make use of the ACPI tables, the operating system must have an interpreter for the AML bytecode."[1] And it's not like this was intended to truly be fully interoperable. "Maybe we could define the APIs so that they work well with NT and not the others even if they are open."[2] [1] https://en.wikipedia.org/wiki/ACPI https://en.wikipedia.org/wiki/ACPI [2] https://issuepedia.org/1999/01/24/ACPI_extensions https://issuepedia.org/1999/01/24/ACPI_extensions
  - AshamedCaptain 3y ago
    This is semantics at this point, but ACPI "is" not executable code. It contains executable code in form of methods, but it is a structured container for many types of data (they are called "tables" for a reason). You could very well embed DT in ACPI and there are platforms out there which do that.

surajrmal 3y ago

Lack of peripheral standardization is a big piece too. You're not going to include every possible arm peripheral driver in your image. There are far fewer drivers necessary to include on PC by comparison (and they are often less space constrained anyways so including those drivers isn't a big deal).

rcxdude 3y ago
It's not much different. PC linux distros already bundle basically all the device drivers for not just the PC box itself but all the peripherals you might plug into it. The ARM ecosystem if anything has fewer peripherals, it's just not upstream.

AshamedCaptain 3y ago

There is also the fact that ACPI allows embedding executable code, which in effect allows system vendors to hide proprietary drivers on it. E.g. HID stuff such as brightness control or keys which do not (generally) need any kernel code to work and are generally impossible to define with DT unless they are simple single-purpose GPIO pins.

trelane 3y ago
ACPI is executable code. "Much of the firmware ACPI functionality is provided in bytecode of ACPI Machine Language (AML), a Turing-complete, domain-specific low-level language, stored in the ACPI tables.[7] To make use of the ACPI tables, the operating system must have an interpreter for the AML bytecode."[1] And it's not like this was intended to truly be fully interoperable. "Maybe we could define the APIs so that they work well with NT and not the others even if they are open."[2] [1] https://en.wikipedia.org/wiki/ACPI https://en.wikipedia.org/wiki/ACPI [2] https://issuepedia.org/1999/01/24/ACPI_extensions https://issuepedia.org/1999/01/24/ACPI_extensions
- AshamedCaptain 3y ago
  This is semantics at this point, but ACPI "is" not executable code. It contains executable code in form of methods, but it is a structured container for many types of data (they are called "tables" for a reason). You could very well embed DT in ACPI and there are platforms out there which do that.