RFC-0069：ELF 執行器中的標準 I/O

RFC-0069：ELF Runner 中的標準 I/O
狀態	已接受
領域	元件架構
說明	ELF 元件的機制可將 stdout 和 stderr 串流轉送至 LogSink 服務。
毛皮變化	480362
作者	yaneury@google.com
審查人員	jamesr@google.com shayba@google.com geb@google.com adamperry@google.com pascallouis@google.com abarth@google.com vaas@google.com cpu@google.com
提交日期 (年-月-日)	2021-02-02
審查日期 (年-月-日)	2021-02-17

摘要

推出兩個新旗標：forward_stdout_to 和 forward_stderr_to 針對要接收 stdout 和/或 stderr 串流。啟用後，系統就會以 LogSink 服務。

提振精神

啟動元件管理員時，其 stdout 和 stderr 串流會 啟動期間沒有其他替代方案，因此繫結至偵錯記錄 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作以 Archivist 這個元件為例 服務本身是由元件管理員啟動

直到「最近」，元件管理員重新導向了所有元件 stdout 和 stderr 串流傳入核心的偵錯記錄檔。這堂課程的 複製元件管理員本身的 stdout 和 stderr 控制代碼 繫結至偵錯記錄 (如上所述)。不過，這會造成一些問題。 首先，使用者模式元件不應因為保留的位址而寫入偵錯記錄 用於核心用量和高特殊權限使用者模式元件，反之， 大部分使用者模式元件都應改為寫入 LogSink 服務。接著 在未明確選擇加入的情況下，提供兩個傳出串流，則違反 最低權限原則。

如今元件管理員完全沒有這項功能 一邊處理先前存在的兩個缺點而不是 默示將 stdout 和/或 stderr 授予所有元件，建議 向 ELF 執行器傳送新標記，以便透過明確的方式選擇加入。

「Component Framework」團隊處於 從 appmgr 的長時間執行遷移作業 (元件 v1) 到元件架構 (Components v2)。一 其中一項主要專案是將 所有網路堆疊團隊擁有的元件stdout/stderr 支援 才能遷移這些元件原因如下 即網路堆疊元件是以 Go 編寫。開始計畫 不同於以 C++ 或 Rust 編寫的程式語言，系統會在執行階段環境中執行， 在設定期間先發出錯誤到 stderr，才開始由開發人員編寫的程式 備用資源由於錯誤會記錄在程式的進入點之前， Go 元件的作者可將 stdout 和 stderr 控制代碼繫結至 記錄服務為解決這個問題，我們可以在 加入必要的記錄初始化，接著才開始執行 使用者編寫的 Go 程式當然，這項解決方案會為 來維護支撐，元件管理員也可以 stdout 和 stderr 在元件 (以及 Go) 之前處理記錄服務 因此會允許擷取錯誤訊息 Fuchsia 的記錄服務。

更廣泛來說，我們將降低 v1 -> 的技術負擔v2 遷移工作appmgr 目前提供 stdout 和 stderr。 會控制所有 v1 元件，並轉送至偵錯記錄檔。因此， 可以合理假設 Fuchsia 許多開發人員這麼做 而不是每個特徵的分數隨著我們邁入 2021 年並開始遷移更多元件， ，讓開發人員能夠維護他們仰賴的 stdout 和 stderr 支援。

需求條件

備份記錄服務必須為 LogSink，而非 debuglog。以下提供 為何我們必須改用 LogSink。首先，Debuglog 是專為核心所設計 以及上述資源的使用情境第二，偵錯記錄檔會使用一個小型 (128 KB) 共用環 緩衝區，並以 FIFO 為基礎輪轉訊息。阿奇維斯特 定期排除這些郵件，並將其轉寄至 LogSink。但有責任發生才會採用 然後再進行 LogSink。使用 LogSink 設定 stdout 和 stderr 記錄服務時，不會排除 但會減少 元件和程序會在使用偵錯記錄時遭到捨棄。 此外，沒有機制可以追蹤緩衝區時損失的金額 旋轉速度超過負荷速度。第三，偵錯記錄檔不支援嚴重性等級 等級 (例如 DEBUG、INFO 等)這項規定十分重要 以區分 stdout 訊息和 stderr 訊息。就記錄問題而言 而只能將每個輸出串流對應至特定的嚴重性等級。

設計

本提案針對 ELF 的 program 領域導入兩個新的列舉值 forward_stdout_to 和 forward_stderr_to 等元件列舉將 為 ELF 元件選用，預設為 none。如果沒有，ELF 執行元件不會將 stdout 和 stderr 控制代碼繫結至 LogSink 服務 (目前行為) 和這些訊息串也將繼續遭到忽略。如果這些情況 值設為 log，ELF 執行元件會建立一個通訊端，用來擷取 stdout 和 stderr 串流的輸出內容。接著會將位元組 讀取 LogSink 服務。如果是 stdout，則會傳送 INFO 訊息； 適用於 stderr，則會傳送 WARN 訊息。訊息會以換行符號分隔。 且每一行都會以不可分割的訊息分割為 LogSink 服務。 LogSink 服務的訊息大小上限為 32KB，因此我們 30 KB (為訊息中繼資料預留一些空間) 的位元組串流緩衝區。 超過邊界的位元組數會遭到捨棄，只有部分訊息會遭到 要傳送到 LogSink 服務。這會引發有趣的極端案例 可將程式碼點分割為 30 KB 邊界。在本例中 就會處理，而無效碼點的前半部會 進行解碼所有輸入位元組都會以 UTF-8 解碼 String::from_utf8_lossy.根據這個函式的 API 所有無效的 UTF-8 序列都將替換為 U+FFFD REPLACEMENT CHARACTER。

{
    program: {
        "runner": "elf",
        "forward_stdout_to": "log",
        "forward_stderr_to": "log",
    }
}

實作

這項功能僅限於 ELF 執行元件，因此必須對 實作起來很小我們預測 CL 不會超過 2 個 以便執行這項變更

成效

由於字行只會輸出至 LogSink，因此效能成本最低。最常出現 這項功能會發生的主要負擔是剖析位元組資料流 以及換行然而，由於 AI 開發程序 花費的成本相當低廉 記錄為不規則作業，位元組串流本身通常為 簡稱為 1,000 次更重要的是，這只會影響明確選擇加入的元件 我們學到的知識因此，如果成效出現問題 解決這個問題，只要將 forward_stdout_to 和 forward_stderr_to 設為 這些元件中的 none，會暫時改回正方形，直到 解決潛在的效能問題

安全性考量

Archivist 已有歸因和流程的機制 功能，因此運作錯誤的元件無法藉由傳送 stdout 來拒絕服務。 因此您不需要額外採取任何行動。但請注意，這項功能 提供將任意位元組置入另一個程序的機制位址空間 (從元件到 Archivist)如果緩衝區太寬，可能會造成問題 可以大幅改善，但我們先前提過，將有助於解決上述問題。此外，自 這個實作方法能盡量減少處理輸入資料流 提升權限這個分析器是複雜的剖析器 錯誤和漏洞都會增加

隱私權注意事項

LogSink 後端和所有 LogSink 用戶端均已遵循隱私權法規， 歸因於來源，且充分 PII 檢查 所採用的機制因此您不需要額外採取任何行動。

測試

除了單元測試之外，我們還會加入整合測試，確保記錄 寫作《Archivist》這些整合測試將以所有受支援的 語言：C/C++、Rust 和 Go因為 Dart 元件不會測試 Dart 執行作業不會由 ELF 執行元件處理。

說明文件

這個標記會記載在以下項目的 ELF 執行器一節： Components v2 文件

缺點、替代方案和未知

編號控點

我們探討了將流程架構升為「元件」的編號控點 支援這項功能的架構。雖然我們決定不認同 大致設計如下：

{
    program: {
        "runner": "elf",
        "handles": ["STDOUT", "STDERR"]
    }
}

ELF 執行元件會讀取常數字串，然後將其對應至適當的 並在內部使用編號控制代碼我們最終決定不採用 不知道後將立即用於其他編號帳號代碼。此外， 找到另一個應在 ELF 執行元件中設定的編號控制代碼 program 規律，讓我們能不斷更新資訊清單檔案語法， ELF 執行元件實作。

元件管理服務

我們也探討了 控制代碼大致的資訊清單檔案設計如下：

{
    use: [
        {
            "handle": "stdout-to-log",
            "from": "framework",
            "number": "STDOUT",
        },
        {
            "handle": "stderr-to-log",
            "from": "framework",
            "number": "STDERR",
        }
    ]
}

基於上述關於 Google 的理由， 有編號的控點 也是因為在元件管理員層級推出 提出新的有關 POSIX 相容性的問題，由元件管理員提出。例如： 所有跑者都必須實作這項功能嗎？執行元件會是什麼樣子 不使用 stdout/stderr，例如「web」執行元件？因此我們決定 提出 POSIX 相容性問題，作為獨立作業環境 此 RFC 1916 範圍

隆重推出新元件

我們也探討瞭如何實作翻譯層 剖析 stdout/stderr 位元組資料流，並轉送至 LogSink 服務， 新元件中，由元件架構團隊擁有及管理不過 經過多次討論後，他認為這種方法可以 我們不得不設計出能保留記錄歸因的方法 記錄訊息的時間。Archivist 運用事件能力 而若為元件來源資訊 (例如路徑名稱) 而擷取所有資訊， 我們使用中間層元件

FDIO

我們也使用 Fuchsia 的 POSIX 相容性進行研究 才能實作這項功能也就是說，這個新型別能夠辨識 stdout/stderr 檔案描述元，並在內部 (fdio 內) 將 輸出至 LogSink。然而，經過幾次討論後，我們決定放棄 來修改 fdio，因為這麼做會導致實作變得更加困難。三 發現有一些極端與 POSIX 相容性的極端案例 使用 fdio 中的 LogSink 轉寄站進行實作。此外，以 fdio 為基礎的實作 都會產生更多不確定性及重複工作或者，如果我們使用 如上所述，通訊端的「立即可用」符合 POSIX 標準。