RFC-0192：Fuchsia 上的设备树

摘要

扁平化设备树（简称“FDT”，简称“设备树”）是一种 广泛用于描述板上硬件布局的格式。它们提供 与 ACPI 大致相似， 抽象层，将更多的复杂性引入操作系统。 FDT 规范定义了一种二进制设备树 blob（“DTB”）格式， 编译设备树 blob 的源格式（“DTS”）。

此 RFC 提出了一种切实可行的方式来引入对设备树的支持 在 Fuchsia 中，无需提交设备树（其布局或二进制文件） 以 ABI 的形式指定）。设备树的确切 ABI 留在板上 定义驱动程序。另请注意，此 RFC 只涉及板驱动程序对设备树的使用。如果内核 解析设备树，则单独的 RFC 将描述上述设备树的格式。

设计初衷

单凭董事会推动了 Fuchsia 的持续增长并不可持续 硬件支持，原因有很多：

1. 我们希望无需 重新组合/重建 Fuchsia 图像。
2. 设备树被开发者广泛使用，我们希望与广大开发者 放置位置设备树还拥有相对强大的生态系统。
3. 当今的书写方式不适合用于协作 多个组织之间。
4. 它们会在固件和板驱动程序之间重复费力进行检测 系统中可用的硬件
5. 在支持多个相关板（即共享层）时，它们无法很好地进行扩展 SoC 或 SoC 系列）。
   • 如需支持多个开发板，其中一个必须在整个开发板中添加条件 板驱动程序，或有多个板驱动程序。
   • 虽然可以通过简洁的方式实现这一点，但最终会更容易 与设备树相比，更加复杂。
   • 设备树让单个开发板更容易支持多个开发板 紫红色图片（但请注意，我们的目标不是“通用” 此阶段的紫红色图片）。

设备树提供了针对这些问题的单一来源， 易于操作的硬件配置真实值， （通过启动固件和工作组均可轻松修改） 而且易于撰写（便于分享 配置）。

请注意，此 RFC 的目标并非完全消除板驱动程序。棋盘 驱动程序仍然是 Fuchsia 驱动程序拓扑的核心部分，即此 RFC 提议使用设备树来补充板级驱动程序， 灵活性。任何无法通过设备树表达的内容 在板级驱动程序中实现。

利益相关方

教员：

cpu@google.com

审核者：

• surajmalhotra@google.com
• curtisgalloway@google.com
• gkalsi@google.com
• bradenkell@google.com
• cja@google.com
• dpursell@google.com

已咨询：

• aaronwood@google.com
• mcgrathr@google.com

社交化：

已在内部分享了此提案的简要概要版本。

术语库

• board Driver - 用于将硬件告知驱动程序框架的驱动程序 。上只有一个板级驱动程序实例 系统。
• 固件 - 首次开机时系统的一部分， 并负责加载和启动 Zircon。

设计

关键字“必须”“不得”“必需”“会”“不会”“应” “不应该”“建议”“可以”和“可选”文档内容 如 IETF RFC 2119。

设备树的角色

设备树仅用于描述硬件布局信息，产品 必须通过 Product Assembly 完成。答 设备树应仅包含关于主板的信息， 而不是配置驱动程序的行为 可能会发生变化，例如预分配的内存缓冲区大小或分区映射。

设备树与 ACPI

我们更倾向于 ACPI，而不是设备树。如果开发板支持 ACPI，则应将其启动 使用 ACPI不得在支持 ACPI 的板上使用设备树。 这是因为 Fuchsia 为每个受支持的设备提供了单个 ACPI 板驱动程序 架构。ACPI 提供更高的抽象级别， 标准化，因此也更容易提供支持。

兼容性

我们的设备树绑定不会尝试保持与 Linux 或 任何其他操作系统，尤其是用于设备驱动程序绑定的操作系统。这仅仅是因为 与 ACPI 不同，设备树没有得到广泛的标准化，确切的布局和 绑定的含义因操作系统版本而异。不过，我们会采用 规范中所述的源文件格式和二进制格式。

Fuchsia 平台不会尝试指定设备的确切格式 我们也不会试图通过单个板驱动程序来支持每个板 - 而是定义一组绑定， 功能（如中断、GPIO、总线）。棋盘 使用设备树的驱动程序应支持此 RFC 中定义的绑定， 但它们可以定义自己的绑定来支持 所需的资源。

我们还将为设备树提供一种方式，为其指定板驱动程序 写入目标（例如，通过根节点的属性，如 fuchsia,board-driver = "vim3-devicetree"），板级驱动程序应使用 确保它们解析的是兼容的设备树。

此外，我们还将定义一个接口，板驱动程序必须向该接口公开该接口 下游驱动程序。此界面与 ACPI 接口，我们将尝试引入 ACPI 和设备树 使驾驶员能够做到完全无关紧要。

将设备树传递给 Fuchsia。

我们已经有一个类型为 ZBI_TYPE_DEVICETREE 的 ZBI 内容。此 ZBI 项是设备树 blob。我们只需在此处进行 更新文档以反映它可能会被板驱动程序使用。

开发板可以选择使用设备树。在这种情况下 引导加载程序会知道这一点，并且引导加载程序应传递设备树 作为 ZBI_TYPE_DEVICETREE 项。如果需要，开发板可以包含设备树 在 ZBI 组装过程中（例如，在制作前 引导加载程序内置对 ZBI 的支持）。

通常，引导加载程序应从非易失性存储空间加载设备树， 验证其真实性，并在运行时将其附加到 ZBI。不过，它们可以 使用备用机制（例如将其编译到引导加载程序中） 如果需要，可以跳过验证（例如对于开发者板）。

Fuchsia 平台实现

我们将为希望实现这组驱动程序的板级驱动程序提供一个库。 绑定。此库将利用现有的设备树解析器 结构体。此外，我们还将实现参考板驱动程序 利用以下库来启动真实系统的设备树。前者 将成为 SDK 的一部分并存在于树中，但后者最终可能会转移至 跳出树。

设备树的可读性

对设备树的一个批评是，源格式可能非常不透明， 因为设备树编译器不支持命名常量。常用方式 解决此问题的方法是使用包含 #define 语句的 C 头文件 为常量声明人类可读的名称，然后将这些 头文件，以便在设备树源代码中使用它们。我们将通过 此方法可在 fuchsia.git 中使用，未来，我们还会支持 生成与绑定库类似的头文件

一般来说，支持与设备树配合使用的驱动程序将拥有一个目录， 包含供设备树源文件使用的头文件。这些标头将定义 在引用驱动程序（GPIO 驱动程序）公开的资源时使用的值 可能具有 PULL_UP、PULL_DOWN 等对应的常量。Devicetree 源文件 构建规则将取决于它们使用的驱动程序，该驱动程序将用于 验证设备树（请参阅文档），并将 提供给 C 预处理器的 include 路径。

设备树的可审核性

为了帮助设备树的可审核性，我们还将引入设备树， “黄金”文件。这些黄金文件将是编译设备时的输出 源代码树转换为二进制文件，然后再返回源代码。这样， 最终设备树上的源代码更改将会被清除。当板级驱动程序和 对设备树进行编译后，我们会对设备树源代码进行编译和反编译， 如果输出与黄金输出不同，构建就会失败。

推出这项功能的动机是，在有多个主板 包含一个通用的设备树源文件（例如，由 SoC）。审核员可能无法立即明显了解 更改“共享的”如何定义设备树文件黄金文件清楚地表明了 每个设备树的最终输出是在设备上使用时。

节点

每个设备树节点都将对应于一个 Fuchsia 设备节点。Fuchsia 设备 节点将是复合节点，这些节点是表示设备的节点的子节点 树节点和表示设备所消耗资源的节点（例如 I2C 设备、GPIO 等）。这类似于 ACPI。请注意，以下示例并非详尽无遗，它们仅仅是 旨在说明我们最初支持的资源类型。其他 未来可根据需要添加资源类型。尤其是 FIDL 本文档中介绍的接口和绑定规则不应 而是用于表明 接口支持的功能。这些接口应该 我们会进行更全面的审核。

设备元数据节点

设备元数据节点将公开以下 FIDL 协议。此协议 旨在用作通用的“非结构化元数据”协议 供其使用的设备驱动程序。

library fuchsia.hardware.metadata;

using zx;

/// Maximum length of a property key.
const PROP_MAX: uint32 = 128;

/// Reasonable maximum for amount of data in a byte array.
const MAX_BYTE_ARRAY_LENGTH: uint32 = 4096;

/// Reasonable maximum length for a string.
const MAX_STRING_LENGTH: uint32 = 4096;

/// Reasonable maximum number of entries for a string array.
const MAX_STRING_ARRAY_LENGTH: uint32 = 4096;

/// Maximum number of properties in a dictionary.
const MAX_PROPERTIES: uint32 = 128;

type Value = flexible union {
    /// True if property is present but has no value.
    1: present bool;
    /// Little-endian 32-bit value.
    2: u32 uint32;
    /// Little-endian 64-bit value.
    3: u64 uint64;
    /// String or string array.
    4: string vector<string:MAX_STRING_LENGTH>:MAX_STRING_ARRAY_LENGTH;
    /// Byte array
    5: bytes vector<uint8>:MAX_BYTE_ARRAY_LENGTH;
    /// Child node.
    6: node Dictionary;
};

type Property = flexible table {
    /// Name of the property.
    1: name string:PROP_MAX;
    /// Value of the property.
    2: value Value;
};

type Dictionary = struct {
    /// List of properties. There may be duplicate property names, in which case the first one should win.
    1: properties vector<Property>:MAX_PROPERTIES;
};


protocol NodeMetadata {
    /// Get unstructured metadata belonging to this node.
    GetMetadata() -> (Dictionary) error zx.status;

};

绑定

每个部分都会介绍设备树绑定以及 功能将用于 Fuchsia。

惯例和标准属性

我们会采用 规范，版本 0.3。

在第 2.3 节中定义的标准属性中，我们可能支持 以下：compatible、phandle、status、#address-cells、#size-cells、 reg、ranges。我们省略了 virtual-reg，因为 MMU 当时的状态 引导加载程序跳到内核与开发板驱动程序无关（因为它 在用户空间中）。我们省略了 dma-ranges 和 dma-coherent 这两个属性 在 Fuchsia 上没有直接对等项。

在 Fuchsia 上：

• compatible - 兼容数组中的第一个值将显示为 绑定属性 fuchsia.devicetree.first_compatible。其他值 以后有更复杂的绑定系统（使用 优先级）。
  • 此外，我们还允许节点定义自己的绑定属性， 可能通过命名空间属性（例如 bind,<prop-name> = <value>）实现， 对应于绑定属性 prop-name（值为 value）。
• phandle - 将用于唯一标识设备内的设备节点 树。由设备树编译器生成，且仅在运行时使用。
• status - 可以在板驱动程序内使用，用于控制是否 节点。我们将调查 status，以及 如果可以显著提高设备树的清晰度，则可以选择省略它 源文件。
  • 具体而言，我们可能希望鼓励编写设备树源文件 （将单个 SoC 定义拆分到多个文件中，并 在最终开发板文件中仅包含必要的代码），而不是 将它们纳入一个，并通过状态 属性。
• #address-cells 和 #size-cells - 将在板驱动程序内用于 以确定其他值的大小。
• reg - 对于可从树的根寻址的节点，将是 由板驱动程序用于确定物理内存区域。这些回忆 区域将通过 GetMmio(int index) 提供给子节点 FIDL 调用，可能通过平台总线驱动程序进行。
• ranges - 在板驱动程序内用于确定子节点如何寻址 范围映射到父级

中断

中断绑定将如 规范。

板驱动程序将为每个中断提供以下元数据 控制器驱动程序：

/// Data for an individual interrupt.
type InterruptData = flexible table {
    /// The cells associated with an interrupt. The size of this vector
    /// is determined by the `#interrupt-cells` property.
    1: cells vector<uint32>:MAX;
};

/// Data for an interrupt controller.
type InterruptControllerData = flexible table {
    /// This vector contains all of the interrupts discovered by the board driver.
    1: configuration vector<InterruptData>:MAX;
};

然后，每个中断驱动程序都会为每个中断发布一个节点。这些节点将 拥有以下绑定规则：

fuchsia.devicetree.node_type == INTERRUPT;
fuchsia.devicetree.phandle == <phandle of interrupt controller devicetree node>;
fuchsia.devicetree.cellN == <nth configuration cell>;

请注意，phandle 是每个设备树的唯一值，只应在 绑定规则。

节点将发布以下 FIDL 服务：

library fuchsia.hardware.interrupt;

protocol Provider {
    /// Return the interrupt represented by this provider.
    Get(struct {}) -> (resource struct { irq zx.interrupt; }) error zx.status;
};

预计在大多数情况下，中断对应于 但在某些情况下（例如 GPIO） 中断可能会多路复用，并且会涉及中间驱动程序。周三 将来可能需要处理这些中断 但该工作不在本文档的讨论范围内。

I2C、SPI、UART 和其他外设总线

这些总线上的设备被建模为其控制器设备的子项。接收者 以确定控制器的总线类型，我们将定义一个额外的“兼容型”值 为每种受支持的总线类型定义价格。例如，i2c 控制器 兼容的值为 fuchsia,i2c-controller。

我们将定义特定于总线的设备树属性，用于填充 Fuchsia 总线驱动程序使用的元数据。这些属性很可能会与 其他操作系统使用的等效格式，但确切格式将是 请参阅 //docs。

代表 I2C/SPI/等总线的节点将称为 i2c000、spi000 等。 请注意，即使设备树只能表示一个父级， 对于这种类型的广告素材，我们仍会对父级进行编号，以便保持与 ACPI 兼容。

GPIO

GPIO 与其他资源的主要区别在于 客户端配置。例如，客户端可能希望启用内部 上拉/下拉电阻，或者引脚可能有效（高/低）。

GPIO 控制器节点必须具有 #gpio-cells 属性，用于定义 用于标识由节点公开的 GPIO 的单元。此外，它必须具有 gpio-controller 属性，该属性为空。

如果 GPIO 控制器节点没有 compatible 字符串，则 系统将改为向 GPIO 控制器节点提供与其 子节点。这适用于具有单个逻辑“控制器”的 SoC暴露 多组 PIN 码库。

我们将定义以下元数据，以便控制器驱动程序了解 每个 Pin 实例的预期配置。请注意，此元数据 设备树特有的不过，我们将为设备树定义一些惯例：

1. 最后一个配置单元包含 GpioConfiguration 标志。
2. 其他单元格分别放置在每个图钉元数据的 data 矢量中。

元数据类型可能如下所示：

library fuchsia.hardware.gpio;

using fuchsia.driver.framework;

/// Maximum number of properties a pin can have.
const uint32 MAX_PIN_PROPERTIES = 32;
/// Maximum number of configuration cells a driver can have.
const uint32 MAX_PIN_CELLS = 8;

/// GPIO configuration flags.
type GpioConfiguration = flexible bits {
    /// If this bit is set, GPIO is active-low. Otherwise, GPIO is active-high.
    GPIO_ACTIVE_LOW = 0x1,
    // more properties here as appropriate.
};

type GpioPinMetadata = flexible table {
    /// Properties the published device should have.
    1: expected_properties vector<fuchsia.driver.framework.NodePropertyValue>:MAX_PIN_PROPERTIES;
    /// Arbitrary, driver-specific data. This will likely encode the pin number.
    2: data vector<uint32>:MAX_PIN_CELLS;
    /// GPIO configuration flags.
    3: flags GpioConfiguration;
};

type GpioMetadata = flexible table {
    /// Standard metadata for GPIO pins.
    /// The GPIO controller driver should publish a GPIO pin node for each of these.
    1: pins vector<GpioPinMetadata>:MAX;
};

此外，GPIO 控制器经常是更大的“引脚控制器”的一部分， 其中一组 GPIO 控制器由单个驱动程序管理。为了支持 如果驱动程序不绑定到单个 GPIO 控制器节点（也就是说， 兼容或设置了其他绑定属性），我们将提供 父节点的元数据。

每个已发布的图钉都应具有以下属性：

fuchsia.devicetree.node_type == GPIO;
fuchsia.devicetree.phandle == <phandle>;
fuchsia.devicetree.cellN == <nth configuration cell>;

想要使用 GPIO 的设备树节点应使用名为 <name>-gpios。这些 fragment 最终将是名为 gpio-<name>NNN 的 fragment 父项。如果 有多个 gpios 被命名，系统将根据其索引为其分配编号。 这些节点应公开 fuchsia.hardware.gpio.Gpio 协议。

如需让驱动程序绑定到 GPIO，则需要如下绑定规则：

node "gpio" {
    fuchsia.resource.name == "example";
    fuchsia.resource.index == 0; // zeroth gpio in the "example-gpios" list.
    fuchsia.hardware.gpio.Gpio == ZirconTransport;
}

稳压器

我们对电压调节器的处理方式与 GPIO 类似，但元数据不会 提供给监管机构驱动程序。系统会根据其使用情况推断出监管机构节点 位于标记为 -supply 的属性中。

单个调节器应对应于单个设备树节点，因此没有 需要进行额外配置。

调节器驱动程序应发布具有以下属性的节点：

fuchsia.devicetree.node_type == REGULATOR;
fuchsia.devicetree.phandle == <phandle>;

一个供应节点只能引用一个调节器。这些 fragment 应该 公开 fuchsia.hardware.vreg.Vreg 协议。

然后，监管机构使用方将使用如下绑定规则：

node "regulator" {
    fuchsia.resource.name == "vdd"; // equivalent to vdd-supply in devicetree.
    fuchsia.hardware.vreg.Vreg == ZirconTransport;
}

时钟和其他资源

您可以为这些设备分配多个实例。

时钟与电压调节器非常相似。由于 时钟驱动程序应知道其导出的时钟数量。时钟控制器节点 应定义 #clock-cells，即识别时钟所需的单元格数量 设备。

它们应具有以下属性：

fuchsia.devicetree.node_type == CLOCK;
fuchsia.devicetree.phandle == <phandle>;
fuchsia.devicetree.cellN == <nth configuration cell>;

时钟使用者可以通过指定时钟标识符数组来定义时钟 （位于 clocks 属性中）和可选名称数组（位于 clock-names 中） 属性。

使用时钟的设备将具有名为 clk-<name> 的 fragment 父级（如果 clock-names），或 clk-NNN，其中 NNN 是时钟的索引 在 clocks 数组中。其中每个 fragment 都会公开 fuchsia.hardware.clock.Device 协议。

如需绑定到时钟节点，驱动程序会使用如下绑定规则：

// If clock-names is expected:
node "clock-input" {
    fuchsia.resource.name == "input";
    fuchsia.hardware.clock.Device == ZirconTransport;
}

// If clock-names is not expected:
node "clock-input" {
    fuchsia.resource.index == 0;
    fuchsia.hardware.clock.Device == ZirconTransport;
}

端到端示例

以 vim3 USB PHY 为例。严格来说， Fuchsia 驱动程序控制两个 USB PHY 和一个特殊的多路复用器，用于路由其中一个 主机和外围设备模式之间的 PHY。

如果我们专注于“多路复用”，部分，它具有 以下资源：

• 一个 MMIO 区域。
• 一个中断。
• 一个时钟。

其设备树节点将如下所示：

/ { // Root node of the devicetree.
    // 64 bit addresses.
    #address-cells = <2>;
    #size-cells = <2>;
    #interrupt-parent = <&gic>;

    usb-mux@ffe09000 {
        compatible = "amlogic,g12b-usb-mux";
        reg = <0x0 0xffe09000 0x0 0xa0>; // MMIO region.
        interrupts = <GIC_SPI 16 INTERRUPT_MODE_EDGE_HIGH>; // Interrupt.
        clocks = <&clk CLK_G12B_USB>; // Clocks.
        clock-names = "usb"; // Clock names.
    };

    gic: interrupt-controller@ff000000 {
        compatible = "arm,gic-400";
        interrupt-controller; // This is an interrupt controller.
        #interrupt-cells = <3>; // 3 32-bit values are used to identify interrupt on this controller.
    };
};

根据此节点布局（具体来说就是 usb-mux 节点）， 设备树板驱动程序将执行以下操作：

• 查看 reg 节点，并将 MMIO 区域从 0xffe09000...0xffe090a0 添加到 平台设备的定义
• 查看中断资源，并向设备组添加中断节点 以及中断部分中所述的属性。
• 查看时钟资源，并使用以下命令向设备组添加时钟节点 时钟部分中介绍的属性。

要绑定到此触摸屏设备，设备驱动程序的复合绑定文件应为 如下所示：

composite g12b_usb_mux;

primary node "pdev" {
    fuchsia.devicetree.first_compatible == "amlogic,g12b-usb-mux";
    fuchsia.hardware.platform.device.PDev == ZirconTransport;
}

node "clock-usb" {
    fuchsia.hardware.clock.Device == ZirconTransport;
    fuchsia.resource.name == "usb";
}

node "interrupt" {
    fuchsia.hardware.interrupt.Provider == ZirconTransport;
    fuchsia.resource.index == 0;
}

请注意，驱动程序看到的绑定属性与用于 因为我们将利用 Google Cloud 提供的转换 API， 设备组。

实现

我们可能会通过多个 CL 引入实现此 RFC 的代码。 实现流程本身不太可能特别复杂 因为在此阶段，系统不会向树外 SDK 添加任何 API。

这些 API 最终将成为驱动程序 SDK 的一部分，但我们首先计划证明 在树内部署设计，以便于快速迭代。

性能

此 RFC 不太可能增加任何明显的运行时性能开销，因为 大多数提议的逻辑在启动时发生一次。

安全注意事项

设备树是由系统固件提供或包含在 ZBI，并且本身是系统中可信的一部分。此外，驾驶人可以 只能访问属于其节点的资源。虽然他们可以检查 子节点的特性和属性，则它们无法访问任何资源， 它们的子节点所拥有，资源访问权限 由板驱动程序通过复合节点的 fragment 父级明确授予的权限。

不过，驱动程序将能够解析设备树中的属性， 如果编写得不够谨慎，就会使它们容易被利用。具体来说， 我们将让驱动程序能够为 它们希望包含在设备树中的配置数据， 解析代码可能容易遭到攻击，因此我们应确保 使用此类配置数据的易于测试（或模糊测试）的驱动程序。

板驱动程序不是 Fuchsia 平台的一部分，因此 设备树库或板驱动程序需要由 这些板驱动程序和新的板驱动程序的所有者需要重建。

隐私注意事项

对设备树的访问权限将受到限制，因为它可能会被用于指纹识别 。

测试

最初，我们将使用单元测试来验证 板驱动程序。最终，我们将使用任意设备进行集成测试 来创建设备拓扑。

我们还会对设备树解析器进行模糊测试。

我们还将提供工具，用于根据已知的 设备树架构。

文档

我们将记录 Fuchsia 使用设备树的情况以及支持 放在 fuchsia.dev 上的文档中。具体而言，我们希望董事会所有者 了解如何在其尝试调出的板上使用设备树 - 了解我们的做法与其他操作系统有何不同，以及如何 才能真正发挥作用

此外，我们还要求驾驶员指定 设备树架构，并将它们包含在 build。为了确保文档符合预期和设备树正确性 我们将实现架构验证 并对照这些架构进行验证

缺点、替代方案和未知问题

缺点：可读性

设备树相对难以阅读。具体而言， 将不同的源文件组合在一起来生成最终输出意味着 您需要解析所有源文件以了解最终结果。

我们希望通过工具（即黄金文件）解决这一问题， 成为使用设备树时的一个阻碍。

替代方案：继续使用纯板驱动程序

我们可以继续以程序化方式表示所有硬件配置， 需要编写代码并重新构建驱动程序，才能表达 更改。如上所述，板级驱动程序并不是可持续的 不断扩展 Fuchsia 的董事会生态系统。

替代方案：使用其他机制描述硬件

我们可以使用另一种基于数据的机制来描述硬件布局。主要 设备树相对于假设的替代方案的优势如下：

• 硬件生态系统参与者广泛使用且熟悉。
• 常见构建块（例如中断支持）定义清晰且易于使用 可采用。
• 我们能够利用现有的工具。

设备树的主要缺点如下：

• 没有明确的跨操作系统标准化工作。大多数活动 以 Linux 为中心。
  • 许多现有绑定专门为 Linux 驱动程序编写。
• 不仅在硬件配置方面（例如产品特定配置）容易滥用 配置）。
• 多个设备树叠加并改变彼此的复杂性 节点（例如 status = "disabled"/status = "okay" 可以停用/启用 节点）。

此外，没有出现设备树的明显替代方案（大多数 系统使用设备树或板级文件来解决这个问题）。设备 自 1994 年开业以来，树木繁茂，已成为 来描述硬件

替代方案：定义由 Fuchsia 平台强制执行的稳定设备树架构

我们可以定义一个设备树架构， 通用“devicetree”开发板驱动程序，并使其成为 设备树。

这样我们就更接近于为所有人添加一张紫红色图片的目标 但设备树的差异很大（相较于 例如 ACPI），这使其是一项庞大的工作，而且很有可能 需要进行大量改进。

此 RFC 不会排除将来采用此类架构的行为，但我们认为 目前，采用设备树的最实用方法是 。

替代方案：利用更广泛的生态系统使设备树绑定保持稳定

我们可以与其他使用设备树的群组合作，使绑定实现标准化 整个生态系统中的各个环节。

这可能是一项多年来的工作，超出了本 RFC 的范围。 Fuchsia 不太可能仅仅因为 绝大多数设备树不是针对 Fuchsia 编写的。

替代方案：使用我们自己的 DSL

我们不用再使用设备树，而是可以发布自己的 DSL， FIDL 和绑定规则。我们未来可能希望这么做 对于这个 DSL 的实现，还没有具体的实现思路 是什么样子如果我们确定将来有必要使用 DSL， 实施此 RFC 后得到的经验对于影响 Google Cloud 的 设计。

先验技术和参考资料

• Linux 和设备树 - 简要介绍 Linux 如何使用设备树。
• 适用于 ARM 的设备树 - 2009 年的一次演讲，当时 Linux 在考虑为 ARM 采用设备树。
• Devicetree：过去、现在、未来 - 2019 年举办的一次关于 Linux 上设备树状态的演讲。
• devicetree.org - 设备树规范 组织。
• ACPI 与 DT - 讨论 统一了 Linux 中的 ACPI 和设备树接口。