RFC-0168：透過 InspectSink 公開檢查

摘要

這個 RFC 導入了允許元件的 fuchsia.diagnostics.InspectSink 通訊協定 顯示檢查資料因此，目前的機制 (DirectoryReady 事件) 現在可以 可能會移除。

提振精神

今天的檢查是透過與一般元件架構不一致的機制公開 能力轉送目前元件會在其傳出命名空間中公開 diagnostics 目錄 架構

DirectoryReady 事件在 RFC-121 中標示為已淘汰，做為發布事件的目標之一 導入的功能然而，對於元件將如何 如果沒有這個目錄，則公開檢查資料。此外，Fchsia 上的 Flutter 想要消除我們對檔案系統抽象化的依賴，並簡化其實作。 重新思考元件公開檢查的方式 相當複雜，且能為開發人員的作業彈性提供優勢。

相關人員

講師：leannogasawara@google.com

審查者：

• crjohns@google.com
• geb@google.com
• shayba@google.com

諮詢：

• dworsham@google.com
• surajmalhotra@google.com
• zarvox@google.com

社交：此 RFC 先前是以 Google 文件形式進行社交， 診斷、元件架構、Flutter 等等。

設計

背景

以前，Archivist 透過 /hub 擷取檢查資料。其程式碼集結構包含 如同目錄監看人員一樣，這個工具會開始追蹤元件資料 out/diagnostics 目錄出現 (過去曾以不同的名稱命名)。這個 最後是透過應用程式 (Appmgr 與元件管理員) 移除與完成 此外，在當時讀取「檢查」資料的測試是直接透過 /hub 讀取。

阿奇維斯目前使用 DirectoryReady 事件有兩個項目：

• 從元件 (元件 expose /diagnostics to framework) 擷取檢查資料。
• 將檢查資料歸因至來源元件。

DirectoryReady 事件會處理這兩個時間點。不過，我們已 CapabilityRequested 代表 (2)，作者認為我們可以協助處理 (1) 期 與 fuchsia.logger.LogSink 相似，可帶來額外優勢。

解決歸因是此 RFC 中的非預期目標。剩下的要歸功於日後移除 CapabilityRequested 事件目前用於 LogSink 和 DebugData。

InspectSink

這個 RFC 導入了 InspectSink 通訊協定，允許 Archivist 擷取檢查資料 從元件載入這項通訊協定的定義如下：

library fuchsia.diagnostics;

using zx;

@discoverable
protocol InspectSink {
    /// Publishes a handle to the `fuchsia.inspect.Tree` protocol that the server can use to read
    /// Inspect data, including lazy nodes.
    Publish(struct {
        tree fuchsia.inspect.Tree;
        root zx.handle:<VMO, zx.rights.BASIC | zx.rights.READ | zx.rights.MAP, optional>;
    });

    /// Publishes a read handle to the inspect VMO  that the component asynchronously updates.
    /// The server can read Inspect using the Inspect reader algorithm [1]. A component using this
    /// method to publish Inspect won't be able to expose lazy nodes.
    ///
    /// [1]: /docs/reference/platform-spec/diagnostics/inspect-vmo-format.md#reader_algorithm
    PublishVmo(struct {
        name string;
        root zx.handle:<VMO, zx.rights.BASIC | zx.rights.READ | zx.rights.MAP>;
    });
}

主要方法是 Publish，大多數元件會使用 fuchsia.inspect.Tree， 執行檢查的標準做法不過我們也提供讓元件 只有檢查 VMO這麼做有幾個原因：

• 元件不一定要是伺服器 (無需執行非同步迴圈，只耗用大量資源) 不需要放送任何項目) 公開檢查。
• 在駕駛人改用 fuchsia.inspect.Tree (問題) 之前，他們會 繼續公開 VMO
• 在 Inspect Dart 程式庫支援 fuchsia.inspect.Tree 之前，必須繼續公開 VMO。

和 fuchsia.logger.LogSink 一樣，這個通訊協定會由 Archivist 提供，並轉送 這些元件

與提供 out/diagnostics 目錄相比，這個通訊協定有幾項優點：

1. 與標準元件通訊協定轉送功能保持一致：

   • 元件只會使用通訊協定 fuchsia.inspect.InspectSink，而不會使用 expose /diagnostics to framework，類似現今的元件匯出記錄和追蹤記錄的方式。
   • 阿奇維斯可以透過 CapabilityRequested 接收與它的連線 出處。

2. 在啟動元件非同步迴圈之前，可以檢查資料。

   • 目錄由 fuchsia.io.Directory 支援，大多數元件都不會提供 out 目錄，直到啟動非同步迴圈為止。使用這項通訊協定，快照即可包含 檢查尚未開始非同步迴圈、但已寫入的元件資料 。

   • 這同樣適用於 fuchsia.inspect.Tree 通訊協定。元件的檢查資料 會顯示於快照中，直到元件開始提供此通訊協定為止，如果 多數情況下，直到元件開始非同步迴圈。只要使用上述提及的通訊協定 就能立即為 Archivist 同時提供根 VMO (因此至少要提供這個) 包含於快照中) 以及 fuchsia.inspect.Tree 的處理常式，適用於日後的要求。

3. 執行器和檔案系統實作程序不會再發生問題。

   • Appmgr 和元件管理工具目前提供程式碼，用於特殊情況下 元件未準時提供 out/diagnostics，也就是 Flutter 執行元件的情況。 執行器會先提供 out/ 目錄，然後填入該目錄。理想情況下 目錄監看員，但並非所有實作 VFS 實作方式 (特別是我們的 在 Flutter 使用的 C++ SDK 中實作 VFS 實作)，也無法仰賴未來的執行器 ，使用完整的 fuchsia.io.Directory 實作。

基本上，您可以變更 inspect/client.shard.cml 來使用 新的通訊協定，而不是向架構公開診斷目錄。檔案 inspect/client.shard.cml 是透過 SDK 提供，所有公開的元件都會使用 隨處檢查。

本提案適用於第 2 版元件。我們仍會在處理 out/diagnostics 的 v1 確保相容性隨著持續遷移至第 2 版，作者無法 認為花時間改變 v1 的運作方式是值得的。這項作業的目標是在 因此遷移至第 2 版的元件不需要變更程式碼公開檢查方式的程式碼。

實作

並按照標準 LSC 程序進行。

具體步驟如下：

1. 在 Archivist 中實作新的通訊協定 InspectSink。
2. 使用 inspect/client.shard.cml 和路徑 fuchsia.inspect.InspectSink 識別元件 我最喜歡的今天，我們將解說 採用 Cml 定義中的這類元件 我們會在後續的 RFC 中補充相關資訊
3. 變更 inspect/client.shard.cml 即可同時使用這個通訊協定和公開 /diagnostics 導入架構，因此可以進行柔性轉換。
4. 支援連線至 InspectSink，而非在檢查中公開 diagnostics 目錄 程式庫
5. 移除元件管理員中 DirectoryReady 的實作，並從 所有元件都轉移與所有預先建構後，即具備 fuchsia.sys2.Event 定義 已重新整理。我們需要仰賴 CTF 測試和支援期，才能確定測試流程 才能達成目標

成效

我們不再需要掃遍目錄，因此效能應該有改善 建立 DirectoryReady 事件，只需要使用單一通訊協定即可。

安全性考量

此變化與元件架構安全屬性一致，尤其是原則 以及階層隔離原則

隱私權注意事項

隱私權異動沒有任何異動。檢查資料仍持續符合一般隱私權程序 這些容器

測試

系統會根據下列方式測試此 RFC 的實作方式：

• 在連線至 InspectSink 的程式庫中測試的單元。
• 在 Archivist 中提供 InspectSink 的單元測試和整合測試。
• CTF 測試，偵測相容性變更。

說明文件

檢查發現和代管功能將更新。

目標是在編寫檢查的程式庫實際進行這項變更。不過， 如此一來，當元件遷移至第 2 版時，程式碼才會變更，我們會在 請參閱遷移指南的診斷部分。

缺點、替代方案和未知

記錄與檢查作業的單一通訊協定

我們可能有一個 DiagnosticsSink，元件可將 Inspect 和記錄檔連結至單一 。

• 優點：僅透過單一通訊協定 (而非 2) 轉送。
• 缺點：如果日後需要處理記錄或進行不同檢查，或許會發生這種情況 相較之下，如果我們維護不同的通訊協定，會降低兩者的通訊協定數量。 我們很快就會深入探討 所以目前先概略介紹

我們認為，記錄和檢查作業各有不同，因此這個替代做法讓這個替代做法變得無趣 因此建議分別轉送

既有藝術品和參考資料

無