RFC-0035：自動追蹤流程

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

在 FIDL 繫結中新增追蹤事件後，就能啟用 Fuchsia 不同程序的端對端流程，而不用手動捲動自訂 ID。
作者
提交日期 (年/月)2019-02-28
審查日期 (年/月)2019-02-28

編輯此 RFC

編輯 RFC 中繼資料

拒絕原因

如果訊息沒有回應 (也就是事件或觸發並忘記呼叫)，交易 ID 會設為 0，因此無法使用建議配置區分。

部分供應商會使用 zx_channel_call()，在核心中指派交易 ID 並等待回覆。(這個模式可讓並行呼叫端依賴核心同步處理，避免系統在指派交易 ID 時鎖定使用者空間)。同樣地，建議的配置無法區分這些配置。

核心追蹤支援功能應提供這項審查所需的遙測功能，且建議您改善這項機制，而非在 FIDL 繫結中推送。

最後，在 SDK 依附元件宣告順序中，使用 FIDL 和使用 FIDL 繫結方式非常接近頂端，因為在 Fuchsia 上過度使用 FIDL。如果在繫結中加入遙測和指標，這類問題就會按照該順序引發這類疑慮，但我們無法對此順序有疑慮。有些建構和選擇加入的技巧可以被判斷，因此需要做為未來提案的一部分。

摘要

在 FIDL 繫結中加入追蹤事件後，無須手動捲動自訂 ID，即可在 Fuchsia 上跨程序進行端對端流程。

提振精神

如果有大量的駭客攻擊，可在 Fuchsia 上跨程序邊界發生流程事件。我們能夠以不會複雜 API 介面且需要減少人工作業的方式，將大部分的自動化作業自動化。

設計

Fuchsia FIDL 函式的標準屬性，可將資料流的開始/結束事件新增至其個別產生的繫結。

這個屬性會設定追蹤記錄的類別，並使用通訊協定函式做為名稱。目前在 Fuchsia 上追蹤僅支援一個類別，因此屬性可能包含「N」類別，我們預期只能使用其中一個類別，並且會使用清單中的第一個類別。

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

專屬的跨程序 ID 是由序數 ID、交易 ID (包含在每則訊息中) 和傳輸機制的 ID (用於 zircon 管道：傳送程序管道控制代碼，以及接收程序控制代碼的相關 koid) 與非密碼編譯雜湊結合。

ZDL 管道中的 FIDL 穩定追蹤 ID 範例

建議您結合下列幾種 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 流程事件。

如果沒有這項功能，則可以在基礎管道讀取和寫入上使用現有 ktrace 流程事件，嘗試達成目標。但這並不理想，因為管道適用於所有 FIDL 介面，這表示只能指定一個類別。這表示為了實際使用，使用者必須啟用管道讀取和管道寫入類別，這表示所有管道讀取和寫入事件 (而非只用於興趣的 FIDL 介面) 的事件都會顯示。這會導致更難以讀取追蹤檢視器輸出內容、不必要的 ktrace 緩衝區使用，並仰賴 FIDL 實作詳細資料。