RFC-0035：自動追蹤流程

RFC-0035：自動流量追蹤
狀態已遭拒
領域
  • FIDL
說明

在 FIDL 繫結中加入追蹤事件，可讓 Fuchsia 中各項程序的端對端資料流，而不需要手動捲動自訂 ID。
作者
提交日期 (年-月-日)2019-02-28
審查日期 (年-月-日)2019-02-28

編輯此 RFC

編輯 RFC 中繼資料

拒絕原因

針對沒有回應的訊息 (例如事件或消防電話) 發送來電 將交易編號設為 0，因此無法透過 提出的配置。

有些用途會使用 zx_channel_call()， 並等待回覆。 (這個模式可讓並行呼叫端依賴核心同步處理， 避免將使用者空間鎖定在交易 ID 指派時)。 同樣地，提出的配置也無法區分。

核心追蹤支援應該會提供遙測功能 另外，我們也偏好改善這項機制 會比在 FIDL 繫結中推送這個值

最後，在 SDK 依附元件挑選器中，使用 FIDL 和 FIDL 由於 Fuchsia 廣泛使用 FIDL，因此與頂層繫結非常接近。 在繫結中納入遙測資料和指標，會導致 但我們對此感到不舒服。 有些「建置及選擇接受」手法可能難以察覺 在您的日後提案中

摘要

在 FIDL 繫結中加入追蹤事件，即可在 Fuchsia 的處理程序，無須手動滾動自訂 ID。

提振精神

駭客有很多需要針對各程序啟用流動事件的入侵方法 Fuchsia 的邊界。 我們可以將大部分的技術自動化，但這些方法不致使 API 變得複雜 並減少人工作業

設計

用於新增流量開始/結束的 Fuchsia FIDL 函式的標準屬性 將事件傳送至其分別產生的繫結。

屬性會設定追蹤的類別，並使用通訊協定 函式。 目前 Fuchsia 追蹤僅支援一個類別，因此， 屬性可能包含 N 個類別，我們預期只有一個 並會使用清單中的第一個字詞

protocol Example {
    [Trace = "CATEGORY"]
    ExampleFn(bool test) -> (bool status);
};

不重複的跨程序 ID 是序數 ID、交易 ID (包含在 以及傳輸機制的 ID (適用於 zircon) 管道：傳送程序管道帳號代碼的 Koid，以及相關 接收程序控制代碼的無異同) 會以 非加密編譯雜湊值

zx 頻道上的 FIDL 穩定追蹤記錄 ID 範例

我們建議結合下列幾種識別碼：

組合這三種 ID 的組合方式應盡可能減少 追蹤記錄 ID 衝突，優先順序如下：

  1. 在兩則不同訊息之間，有相同序數，以及 相同的用戶端和伺服器
  2. 在兩則不同訊息之間，有差異，以及 相同的用戶端和伺服器
  3. 在兩則不同的訊息之間，有差異，以及 不同的用戶端和伺服器

目前，Koid 指派順序大致為依序。 因此，最矮的動物會比 位元 同理，交易 ID 會依序指派，因此提供更多優惠 進行編碼 方法序數即使最高位元也會經過加密編譯 不過，如果是系統使用，您可以放心假設所有位元 相同的熵

因此，在現有情況下，合理的演算法是 OR：

  • koid & OxFFFF << 48
  • ordinal & 0xFFFFFFFF << 16
  • transaction ID & 0xFF << 0

追蹤記錄時長也會在 FIDL 繫結的接收端開始。 在 C++/Rust 等語言中，系統會使用 RAII 限定範圍， 事件，可與另一個流程事件合併。

人體工學

這樣追蹤系統更容易使用，對 基礎架構

說明文件和範例

本說明文件應更新，示範如何新增追蹤記錄 (如下文所述) )。

回溯相容性

這項變更與 API 相容，且與 ABI 相容。

成效

這會在停用追蹤類別時產生小額費用，但較少 每個 dje@google.com 測試 (在 NUC 上) 超過 5 奈秒。 我們也可以假設 IR 的追蹤註解數量 高效能

安全性

安全無虞。

缺點、替代方案和未知

替代方案

核心追蹤機制

利用管道讀取和管道寫入作業現有的 ktrace 流程事件。

如果沒有這項功能，您可以嘗試 方法是使用 可讀取及寫入 但這並不理想，因為所有 FIDL 的頻道都是通用的 介面，代表只能指定一個類別。 也就是說，如要實際使用，使用者必須啟用 管道讀取和管道寫入類別代表所有管道 和寫入事件 (不僅是用於 FIDL 的事件) 可能需要的介面)。 這會導致難以讀取追蹤檢視器輸出內容、不必要的 ktrace 也會依賴 FIDL 實作詳細資料。