RFC-0101：含編號控制代碼的動態元件

RFC-0101：含編號控點的動態元件
狀態	已接受
領域	元件架構
說明	用於將編號控點傳遞至動態元件。
毛皮變化	531642
作者	lindkvist@google.com geb@google.com
審查人員	bryanhenry@google.com geb@google.com cgonyeo@google.com shayba@google.com thatguy@google.com
提交日期 (年-月-日)	2021-05-18
審查日期 (年-月-日)	2021-06-02

摘要

本文件建議在 fuchsia.sys2.Realm/CreateChild。這個參數會包含一組編號 控制代碼已建立元件的「執行器」會收到這些帳號代碼 當系統要求執行元件時提供的帳號代碼只會是 適用於在具有新耐用性類型的集合中執行的元件： single-run。集合中具備以下項目的耐用性： single-run 會在建立時啟動，並在停止時刪除。這個範圍 提供的控制代碼對元件單次執行

提振精神

Starnix 是用於執行 Linux 二進位檔的元件架構 v2 執行器 在 Fuchsia 的幫助下。Starnix 實作 Linux 系統介面來執行這些二進位檔 未經修改。

Starnix 提供 ffx 外掛程式，可讓使用者執行 Linux 元件 建立虛擬機器Starnix 想將 Linux 元件的 stdin/stdout/stderr 轉換為三個通訊端控點。 此元件不會藉由公開 FIDL 通訊協定與系統互動。 而會透過所提供的通訊端與使用者互動。

設計

背景

元件架構包含生命週期轉換的兩個維度。 第一項與存在關係 (Created 和 Destroyed) 有關。第二個 與元件的執行作業 (Started 和 Stopped) 有關。在其他 其中只有程序，而非元件 是相同的：建立程序與開始程序相同， 系統就會在容器停止執行時加以刪除。

提供 Created 和 Started 時，應區分兩者 元件引數通常可以啟動單一元件執行個體 因此元件管理員必須多次把引數 都會在每次執行元件時提供這些函式如果引數會處理這個情況 因為並非所有帳號代碼都會重複任何無法複製的項目 因此會「消耗」就會透過元件執行一次

通訊協定更新

如「背景」所述，建立元件的方式與 馬上開始因此，提供給 CreateChild 的帳號代碼必須是以下任一種：

1. 每次啟動元件時皆可使用。
2. 範圍限定為元件的單次執行。

因為並非所有帳號代碼可以重複 (儲存在 隨後的執行作業)，(1) 只有在從 並在每次執行時 測試映像檔的原始碼請參閱轉送 會解釋為何這種架構 未選擇啟動時擷取的控點。幸好 (2) 是可行的解決方案 大膽使用案例

已建立新資料表 ChildArgs，並新增為 Realm/CreateChild：

protocol Realm {
  /// If args contains numbered_handles, the collection must have a durability
  /// of type `single-run`.
  CreateChild(CollectionRef collection, ChildDecl decl, ChildArgs args)
      -> () error fuchsia.component.Error;
}

resource table ChildArgs {
  /// The numbered handles for the component instance.
  ///
  /// Only PA_FD and PA_USER* handles are valid arguments, and inclusion of any other
  /// handles will result in an error.
  1: vector<fuchsia.process.HandleInfo>:N numbered_handles;
}

此外，fuchsia.component.runner.ComponentStartInfo 資料表會是 更新為包含編號控點：

resource table ComponentStartInfo {
  6: vector<fuchsia.process.HandleInfo>:N numbered_handles;
}

執行器會提供元件的控點，或是關閉並返回 如果執行元件不支援提供編號控點 元件。

系列作品耐用性

透過 Realm 通訊協定建立的元件位於集合中。 集合包含代表生命週期的 durability 註解 集合中的元件語意包括

系統會新增集合 durability 值「single-run」來表示 集合中的元件會在建立時立即啟動 並在容器停止時刪除ChildArgs.numbered_handles 只能 與標示 single-run 的集合搭配使用。這會限制 ChildArgs 對元件的單一執行作業。

collections: [
    {
         name: "playground",
         durability: "single-run",
    }
],

實作

元件管理員將更新以儲存 ChildArgs，直到傳遞為止 處理 single-run 集合語意

回溯相容性

此變化與跑者的回溯相容：跑者不是 才能使用我們提供的編號帳號代碼。如果執行元件並未 支援編號化控制代碼預期關閉帳號代碼。

這項變更不適用於 Realm 用戶端。

此變更與 CML 的回溯相容： 唯一的變更是 並新增耐用性列舉

成效

這個帳號代碼會直接提供給 元件管理工具

安全性考量

這項變更導入了一個可讓家長將任意編號帳號代碼傳遞給 。進行這些帳號代碼的交換作業是由元件和 經理和執行元件僅限在標示為集合中執行的元件 single-run 可以採用這個方式接收帳號代碼。

測試

CreateChild 的現有測試將免除，以涵蓋新的 引數。

缺點、替代方案和未知

缺點

與提議的解決方案相比，您提出的解決方案仍有以下幾個缺點 替代做法：

• 這是啟動元件的新方式：元件的生命週期不會 並受到能力繫結影響
• 提供的控點不適用於元件架構的靜態 CML 以便查詢及分析
• 由於接收控制代碼的元件會在停止時遭到刪除， 也會抹除永久儲存空間因此，使用永久儲存空間 儲存空間並非這項功能的理想選擇。

銀行代碼做為用途

元件架構可以明確設定路由編號控制代碼。

達到這個目標的方法有很多種 下方的「形狀」。

引入一個由編號結果來源實作的通訊協定 帳號代碼：

protocol HandleProvider {
    Get(string handle_name) -> (fuchsia.process.HandleInfo handle);
}

接著，這個通訊協定就會變成能力：

capabilities: [
    {
        handle_provider: "stdin",
        path: "/svc/fuchsia.component.HandleProvider",
    },
],
expose: [
    {
        handle_provider: "stdin",
        from: "self",
    },
],

另一個則是透過 CML 轉送至目的地 這些功能。

優點

• 可修改，以支援更多帳號代碼類型資訊。
• 讓元件明確可見控點路徑 這個架構的重點在於

缺點

只有在擷取帳號代碼後，元件才能開始。 即使在 實際上，激勵用途就沒有好處 每次執行元件時都會有不同的控制代碼。提案中 主機程式碼可能會「啟動後忘記」用於啟動元件的要求 並繼續執行，就像呼叫成功一樣。在這個替代版本中， 主機程式碼需坐下並旋轉，等待相關的帳號代碼要求 即可返回

處理常式不一定能透過靜態路由存取。在 處理用途的應用實例，該帳號代碼在主機機器上，已連線至 透過 Overnet 使用 Fuchsia 裝置。可以透過轉送「盡可能規劃」功能來解決這個問題 然後將「edge」元件透過臨時機制擷取控點 然後再傳回元件架構這會造成額外負擔 需要使用這項功能的開發人員

帳號代碼提供者無法區分處理要求與 特定能力路徑具體來說，請思考這個激勵用途：

1. 使用者會從主機啟動兩個 Linux 元件，分別位於不同的終端機中。
2. 元件會在集合中執行個體化。
3. 處理常式提供者會收到關於同一個帳號代碼的兩個要求。

目前，處理常式無法知道哪個元件 和帳號代碼要求相關聯如要解決這個問題 額外的用戶端識別機制，不過這次採用 更加複雜

這個解決方案的承諾更多，也比提案的設計更複雜。 儘管如此，我們提出的設計並不會預防或與煽情露骨內容衝突 日後可轉接編號的控點。

StartChild

這個替代方案建議將編號控點以引數形式加入 Realm有 StartChild 通來電。這與提議的設計類似 在元件繫結至能力之間導入競爭的缺點 (啟動元件) 和 StartChild 撥號中。具體來說，元件只會收到 會控制 StartChild 呼叫是否贏得賽跑，因為不確定如何 如果元件已啟動，便會傳送控制項。

入門通訊協定

傳遞編號帳號代碼可透過 Starter 通訊協定完成。啟動條件 可用於啟動元件，而是由元件實作 代表元件管理員，且可以像任何其他通訊協定一樣轉送 (也就是說，元件可由非其父項的元件啟動)。

這個通訊協定可像任何其他通訊協定一樣轉送，因此用戶端可使用該通訊協定來 位於元件中任意位置的起始元件 階層

啟動條件通訊協定包含一個方法，可將編號控點做為引數：

[Discoverable]
protocol StarterWithArgs {
    /// Start the component that is bound to this protocol.
    /// If the component is already running, the call returns an error.
    Start(StartArgs start_args) -> () error fuchsia.component.Error;
};

這個提案和 StartChild 非常類似。通訊協定會遭到 這樣的好處是更容易稽核及加入許可清單，而且 導入 Start 與繫結至任何其他能力之間的競爭 同一個元件此外，訂購問題也加深 但用戶端不一定是父項，因此不一定能重新啟動 來提供引數加入停靠點即可解決這個問題 方法新增至通訊協定

客戶也需要在啟動條件之間協調子項管理 通訊協定和領域通訊協定，不必單獨管理子項 將透過運作領域通訊協定