RFC-0192：Fuchsia 上的裝置樹狀結構

RFC-0192：Fchsia 上的裝置樹狀結構
狀態已接受
領域
  • 裝置
說明

使用裝置樹狀結構描述硬體配置的策略
問題
蓋爾特變化
作者
審查人員
提交日期 (年-月-日)2022-08-03
審查日期 (年-月-日)2022-10-01

編輯此 RFC

編輯 RFC 中繼資料

摘要

扁平化裝置樹狀結構 (「FDT」或「devicetrees」) 為 用來描述主機端硬體配置的格式。他們在 與 ACPI 相似，不過前者的運作模式 並對作業系統執行更複雜的攻擊 FDT 規格定義了二進位 devicetree blob (「DTB」) 格式，以及 (「DTS」) 用來編譯 devicetree blob 的來源格式。

這個 RFC 提議以務實的做法，導入對 Devicetree 的支援。 不必另外投入裝置樹狀結構 (版面配置或二進位檔) 格式) 做為 ABI。具體而言，裝置樹狀結構的確切 ABI 是由車輛自行上路。 定義本身和韌體。另請注意，此 RFC 僅涉及桌上駕駛人使用 Devicetree 的情形。如果核心是，或者在核心 剖析 devicetree 則另外提供 RFC 會說明指定 devicetree 的格式。

提振精神

為了繼續壯大 Fuchsia，光靠衝浪板駕駛並非符合永續精神的做法 基於以下原因：

  1. 我們希望能反覆進行硬體設定、 重新組裝/重新建構 Fuchsia 圖片。
  2. 開發人員廣泛使用 Devicetree，但我們希望能認識開發人員 以及他們的位置Devicetree 的生態系統也相對穩定。
  3. 現代人採用這種寫作方式時，不適合用於協作 可讓員工相互交流。
  4. 它們會導致韌體和主機板驅動程式庫之間重複進行偵測 具備在系統中使用的硬體
  5. 在支援多個相關董事會時 (即共用 SoC 或 SoC 系列)。
    • 如要支援多個主面板，其中一個面板必須新增條件式 或使用多個主機板驅動程式
    • 雖然能以簡潔的方式完成這項作業，但最終會比較容易 而不是只有 devicetree 的密碼
    • 使用 Devicetree，就能輕鬆以單一方式支援多個 Jamboard Fuchsia 圖片 (請注意，我們不會以「通用」做為目標 這個階段的 Fuchsia 圖片)。

Devicetree 提供單一資料來源 可以輕鬆單獨處理所有硬體設定 系統的其餘部分 (易於啟動韌體，以及根據運作中的小組修改兩者) 以及輕鬆撰寫郵件 (方便分享 採用相同的 SoC 系列設定)。

請注意，此 RFC 的目的並非完全消除主機板驅動程式，棋類 驅動程式仍是 Fuchsia 驅動程式庫拓撲的核心部分，此 RFC 提議使用裝置樹狀圖來補充董事會司機，以提升 更加靈活彈性任何能用裝置樹狀結構無法表達的內容 並在 Jamboard 驅動程式庫中實作

相關人員

講師：

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

社交功能：

這份提案的簡短摘要為內部共用。

詞彙解釋

  • 桌遊驅動程式 - 告知驅動程式庫程式架構的驅動程式 每個物件單一主機上只有一個主機板驅動程式庫程式執行個體 有些人會將 Cloud Storage 視為檔案系統 但實際上不是
  • 韌體 - 開機時執行的系統部分， 負責載入及啟動 Zircon

設計

下列關鍵字：「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「應該」、 「不應該」、「建議」、「可能」和「選用」基本上就是 解讀方式 IETF RFC 2119。

Devicetree 的角色

Devicetree 只用於說明硬體版面配置資訊。產品 設定「必須」透過產品組裝完成。A 罩杯 devicetree 只能包含與主機板相關的真實資訊， 而不是設定駕駛人行為 例如預先配置的記憶體緩衝區大小或分區對應

Devicetree 與 ACPI

我們建議將 ACPI 改為 devicetree。如果主機板支援 ACPI，則應啟動裝置 使用 ACPI車上如果支援 ACPI，則「不得」使用 Devicetree。 這是因為 Fuchsia 針對每項支援的 這個架構的簡短總覽ACPI 提供的抽象層級越高 標準化也因此更易於支援

相容性

我們的 devicetree 繫結不會嘗試維持與 Linux 或 其他作業系統，特別是裝置驅動程式庫繫結。這只是因為 裝置樹狀結構與 ACPI 不同，裝置樹狀圖則沒有廣泛標準化的 繫結的意義因 OS 版本而異。不過，我們會採用 如規格中所述，來源及二進位格式。

Fuchsia 做為平台不會嘗試指定確切的裝置格式 也不會因為我們的目標是讓每個董事會都支援一個主面板 而是會定義一組繫結，為 例如中斷、GPIO、公車)。棋類 使用 devicetree 的驅動程式應支援此 RFC 中定義的繫結 但可以定義自己的繫結來支援額外功能 。

我們也會讓裝置樹狀圖指定桌遊驅動程式庫 寫入目標 (例如透過 fuchsia,board-driver = "vim3-devicetree") 使用的主機板驅動程式 確保這些伺服器剖析相容的 Devicetree。

此外，我們也會定義 主面板「必須」公開的介面 下游驅動程式這個介面與 ACPI 介面，且我們希望提供 ACPI 和 devicetree 彼此互通，方便駕駛人區分兩者。

將 Devicetree 傳遞至 Fuchsia。

我們已有一個類型為 ZBI_TYPE_DEVICETREE 的 ZBI 項目。這項內容的內容 ZBI 項目是 devicetree blob。這裡唯一的變更是 更新說明文件，以表示主機板驅動程式庫可能會使用。

董事會「可能」選擇使用 devicetree。遇到這種情況是正常情況 系統啟動載入程式會知道這一點，且系統啟動載入程式必須傳遞 做為 ZBI_TYPE_DEVICETREE 項目。如有需要，看板可以提供 Devicetree 服務 直接在 ZBI 中組建後 (例如在啟動前 系統啟動載入程式已內建 ZBI 支援)。

一般而言，系統啟動載入程式應從非揮發性儲存空間載入裝置樹狀結構。 驗證其真實性，並在執行階段將其附加至 ZBI。但他們可能 使用其他機制 (例如將其編譯至系統啟動載入程式) 並視情況略過驗證程序 (例如開發人員董事會)。

Fuchsia 平台導入

我們將為有意實作這套工具的桌遊提供程式庫 繫結。這個程式庫會使用現有的 devicetree 剖析器 也就是樹狀結構中此外，我們也會實作參考板驅動程式庫 以及利用這個程式庫啟動實際系統的裝置樹狀結構前 會包含在 SDK 中，並位於樹狀結構中，但後者最終可能會 。

Devicetree 可讀性

devicetree 的一個批評是，來源格式可能非常不透明 因為 devicetree 編譯器不支援具名常數。常見的 解決方法是使用包含 #define 陳述式的 C 標頭檔案 這會宣告常數的人類可讀名稱， 標頭檔案，以便用於 devicetree 來源。我們會實作 我們日後也會支援這項做法 從繫結程式庫產生類似的標頭檔案

一般而言，支援與 devicetree 搭配使用的驅動程式會有目錄 包含可供 devicetree 來源檔案使用的標頭。這些標頭會定義 參照驅動程式庫公開的資源 (GPIO 驅動程式庫時使用的值 PULL_UP、PULL_DOWN 等都有常數。Devicetree 來源檔案 接著根據要使用的驅動程式 建構規則 驗證裝置樹狀結構 (請參閱「說明文件」)，並 提供給 C 預先處理器的 include 路徑

裝置樹狀結構是否可供審核

為方便審查裝置樹狀結構，我們也將推出裝置樹狀結構 「黃金」檔案。這些黃金檔案將是編譯裝置的輸出內容 先將樹狀結構來源分入二進位檔，再回到原始碼，即可 最終 devicetree 中的來源變更會清楚顯示當 Jamboard 驅動程式庫 我們會編譯並反編譯 devicetree 原始碼 如果輸出內容與黃金不同，就會失敗。

這項功能的動機在於，假設有好幾個主面板 其中包含常見的 devicetree 來源檔案 (例如 SoC)。審查人員可能無法立即得知 變更「共用」devicetree 檔案。黃金檔案能讓我們清楚知道 每個 devicetree 的最終輸出內容即為在裝置上使用。

節點數

每個 devicetree 節點都會對應至一個 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。

慣例和標準屬性

我們會採用第 2.2 節所述的慣例， specification 0.3 版。

對於第 2.3 節所定義的標準資源，我們或許可以支援 下列屬性：compatible、phandle、status、#address-cells、#size-cells、 reg、ranges。我們省略了 virtual-reg，因為 MMU 當時的狀態 系統啟動載入程式跳至核心與 Jamboard 驅動程式庫無關 (因為 在使用者空間中)。我們省略了 dma-ranges 和 dma-coherent，因為這些屬性 沒有與 Fuchsia 直接同等的功能。

Fuchsia：

  • compatible - 相容陣列中的第一個值會顯示為 繫結屬性 fuchsia.devicetree.first_compatible。其他值 日後可使用更複雜的繫結系統 優先順序)。
    • 此外，我們將允許節點自行定義繫結屬性 可能來自命名空間屬性 (例如 bind,<prop-name> = <value> 會對應至屬性 prop-name 和值 value)。
  • phandle：用於識別裝置中的裝置節點 。由 devicetree 編譯器產生，且只在執行階段使用。
  • status - 可在主板驅動程式庫中使用，以控制 節點我們會針對略過廣告的必要性進行調查 實作此 RFC 期間，來自支援的繫結的 status，以及 如果可以大幅改善裝置樹狀結構的清晰度，則可選擇省略 來源檔案。
    • 具體來說，我們鼓勵開發人員編寫 devicetree 來源檔案 單一的 SoC 定義，藉此定義多個檔案 僅納入最終板檔案中的必要項目)，而非 包括在內，並透過狀態停用/啟用 IP 封鎖 資源。
  • #address-cells 和 #size-cells - 用於輔助面板驅動程式庫，以便： 會影響其他值的大小
  • reg - 對於可從樹狀結構根定址的節點，將會是 決定實體記憶體區域。這些個人化記憶 子節點可透過 GetMmio(int index) 提供給子節點 FIDL 呼叫，可能透過月台匯流排驅動程式。
  • 範圍 - 自動在板驅動程式庫中，用來判斷子項地址 範圍對應至父系

中斷

「中斷繫結」定義如下所述第 2.4 節： 規格。

每次中斷時，主機板驅動程式庫都會提供下列中繼資料 控制器驅動程式庫：

/// 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 等等。 請注意，雖然 devicetree 只能代表單一父項 仍是以與 ACPI 相容的父項為準。

GPIO

GPIO 與其他資源的主要差異在於 用戶端設定。舉例來說，客戶可能想啟用 升降式阻力器，或是針腳可能響起/低下。

GPIO 控制器節點必須有 #gpio-cells 屬性，並定義號碼 識別節點所公開 GPIO 的儲存格。此外，亦必須 gpio-controller 屬性，沒有任何內容。

如果 GPIO 控制器節點沒有 compatible 字串，則 系統會改為提供 GPIO 控制器節點與 子節點這種做法適用於單一邏輯「控制器」的 SoC公開 由多組 PIN 碼組成。

我們將定義下列中繼資料，讓控制器驅動程式知道 以瞭解每個 接腳執行個體的預期設定請注意，這個中繼資料並不是 特定 devicetree 專屬。不過，我們會對裝置樹狀結構定義一些慣例：

  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 的 Devicetree 節點應使用命名為 <name>-gpios。這些組合最終會是名為 gpio-<name>NNN 的片段父項。如果 系統會為多個 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。

單一監管人員應對應單一 devicetree 節點，因此 必須進行額外設定

法規驅動程式應發布含有下列屬性的節點：

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

供應節點只能參照單一監管員。這些片段 公開 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>;

時鐘消費者可以指定時鐘 ID 陣列來定義時鐘 clocks 屬性中的選用名稱陣列，以及 clock-names 中的選用名稱陣列 資源。

使用時鐘的裝置會有名為 clk-<name> 的片段父項 (如果 使用 clock-names) 或 clk-NNN，其中 NNN 是時鐘索引 在 clocks 陣列中載入。每個片段都會公開 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。

如果我們將重點放在「mux」這個方程式的一部分 下列資源：

  • 一個 MMIO 區域。
  • 單次幹擾。
  • 一個時鐘。

其 devicetree 節點看起來像這樣：

/ { // 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 節點)， Devicetree board 驅動程式庫會執行以下作業：

  • 請參閱 reg 節點，並將 0xffe09000...0xffe090a0 中的 MMIO 區域新增至 平台裝置的定義
  • 查看中斷資源，並在裝置群組中新增中斷節點 中斷一節中說明的屬性。
  • 查看時鐘資源，並在裝置群組中新增時鐘節點 請參閱時鐘一節中所述的屬性設定屬性。

如要繫結與這部觸控螢幕裝置，裝置驅動程式庫的複合繫結檔案 如下所示：

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;
}

請注意，驅動程式庫看到的繫結屬性不同於 因為我們會使用 裝置群組。

實作

我們可能會針對許多 CL 導入實作這個 RFC 的程式碼。 導入程序本身不太可能特別複雜 因為在這個階段，系統不會將任何 API 加入樹狀結構外 SDK。

這些 API 最終會成為驅動程式庫 SDK 的一環，但我們打算先證明 在樹狀結構中，更容易快速疊代

成效

這個 RFC 不太可能會增加任何大量的執行階段效能負擔，因為 大多數建議的邏輯都在啟動時發生。

安全性考量

devicetree 是系統韌體提供的二進位 blob，或 ZBI 本身就是系統受信任的部分，此外，駕駛人 只能存取屬於其節點的資源儘管他們可以檢查 和子節點的屬性，無法存取任何資源 資源存取權 由主機驅動程式庫透過複合節點的片段父項明確授予。

不過，駕駛人可以從 devicetree 剖析屬性， 如果未妥善編寫，就會使漏洞容易遭受攻擊。我們要用 我們會開放駕駛人定義 這些物件會納入裝置樹狀結構中 因為剖析程式碼可能很容易受到剝削，所以我們要確保 易於測試 (或模糊) 使用這類設定資料的驅動程式。

主機板驅動程式庫不屬於 Fuchsia 平台，因此任何 這就需要由 同一台桌上司機的主人和新車板驅動程式庫都必須重新打造

隱私權注意事項

裝置樹狀結構可用於指紋，因此會受到限制 裝置。

測試

一開始，我們會使用單元測試來驗證 也同樣重要最後，我們會使用任意裝置進行整合測試 來建立裝置拓撲

我們也會模糊裝置樹狀結構剖析器。

我們也會提供相關工具，協助您根據已知 devicetree 結構定義。

說明文件

我們將記錄 Fuchsia 對 Devicetree 的使用行為，以及我們如何支援 安裝於 fuchsia.dev 的文件中具體來說，我們希望董事會擁有者 瞭解如何在想啟動的 Jamboard 上使用 devicetree - 瞭解我們的做法與其他作業系統有何不同，以及如何 實際的運作方式

此外，我們也會要求駕駛人指定 預期使用的裝置目錄結構定義並加入的 建構應用程式確保說明文件符合預期和裝置樹狀結構的正確性 我們將實作結構定義驗證，讓正式版裝置樹狀結構可以 依據這些結構定義進行驗證。

缺點、替代方案和未知

缺點：可讀性

裝置樹在閱讀上相對困難。尤其是 結合多種來源檔案並產生最終輸出內容 您必須剖析所有來源檔案，才能瞭解最終結果。

我們希望利用工具 (也就是所謂的黃金檔案) 來解決這個問題， 造成使用者操作上的不便

替代做法：繼續使用純板驅動程式

我們可以繼續透過程式 因此必須撰寫程式碼並重建驅動程式庫 並輸入變更內容如上所述，在 繼續拓展 Fuchsia 的董事會生態系統。

替代方法：使用其他機制描述硬體

我們可以使用其他資料式機制來描述硬體配置。主要 與假設替代方法相比， devicetree 的優點如下：

  • 廣泛使用且熟悉硬體生態系統的參與者。
  • 通用的建構模塊 (例如中斷支援) 的定義明確且易於使用 也能採用
  • 我們可以使用現有的工具。

裝置樹狀結構的主要缺點如下：

  • 沒有明確的跨作業系統標準化作業。活動大多是在 也就是 Linux
    • 許多現有繫結僅供 Linux 驅動程式使用。
  • 比硬體設定 (例如特定產品) 更容易遭到濫用 設定)。
  • 如果多個裝置樹狀結構重疊並改變彼此 節點 (例如 status = "disabled"/status = "okay" 可停用/啟用 節點)。

此外，Devicetree 沒有明顯的替代品 (大部分是 系統會使用 devicetree 或 Jamboard 檔案來解決這個問題)。裝置 樹木從 1994 年開始至今，是可靠的 但在說明硬體方面

替代做法：定義由 Fuchsia 平台規定的穩定 devicetree 結構定義

我們可以定義一個支援單一 Devicetree 的結構定義 通用的「devicetree」讓 Kubernetes 瞭解 Devicetrees。

如此一來，我們就更接近目標為所有人 系統採用 devicetree 但變異數相當大 (相較於 像是 ACPI 這類項目相當龐大 因此需要執行大量的演化

此 RFC 雖未排除日後採用這類結構定義的依據，但我們認為 目前，採用 devicetree 是最可行的方法 即可。

替代做法：運用更廣泛的生態系統，穩定裝置樹狀結構繫結

我們可以與其他使用 devicetree 建立繫結標準化的其他群組合作 可以促進社群共同發展

這可能需要花費數年的時間，超過 RFC 的範圍。 不可能直接完成這樣的工作 大多數的裝置樹都不是為富希西亞撰寫的。

替代做法：推出自己的 DSL

與其使用裝置樹狀圖，我們得自行推出整合 Google 技術的 DSL FIDL 並繫結規則。我們日後可能會考慮這麼做 撰寫時，這個 DSL 並無具體的導入提案 程式碼看起來會像這樣如果我們確定日後有必要使用 DSL， 認為實施此 RFC 相關經驗的改善，將有助於影響其 設計。

既有藝術品和參考資料