RFC-0035：自動追蹤流程

拒絕原因

沒有回應的訊息 (無論是事件或即發即忘呼叫) 的交易 ID 會設為 0，因此無法使用建議的配置區分。

部分用途會運用 zx_channel_call()，在核心中指派交易 ID，並等待回覆。(這種模式可讓並行呼叫端依賴核心同步，避免使用者空間鎖定交易 ID 指派)。同樣地，提議的架構無法區分這些項目。

預計核心追蹤支援功能會提供這項審查所需的遙測資料，且偏好改善這項機制，而非在 FIDL 繫結中推送這項機制。

最後，在 SDK 依附元件的優先順序中，由於 FIDL 在 Fuchsia 上廣泛使用，因此使用 FIDL 和 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，以及接收程序控制代碼的相關 koid)，並以非加密雜湊值雜湊處理。

透過 zx 管道傳輸 FIDL 的穩定追蹤 ID 範例

我們建議結合使用下列幾個 ID：

• FIDL 通道伺服器端的 koid，可透過 zx_object_get_info()、ZX_INFO_HANDLE_BASIC 主題取得，方法是使用伺服器端的 koid，以及用戶端上的相關 koid；
• 交易訊息的方法序數 (注意：這目前是 uint32 雜湊值，不久後會演變為 uint64 雜湊值，請參閱 RFC-0029)；
• 最後是交易訊息的交易 ID。

組裝這三個 ID 時，應盡量減少可能的追蹤 ID 衝突，優先順序如下：

1. 兩則不同訊息之間，且序數相同，以及相同用戶端和伺服器之間；
2. 兩個不同訊息之間，且序數不同，以及相同用戶端和伺服器之間；
3. 兩個不同訊息之間 (序數不同)，以及不同用戶端和伺服器之間。

目前 koid 指派作業大多是循序進行。因此，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 實作詳細資料。