RFC-0035:自動追蹤流程 | |
---|---|
狀態 | 已遭拒 |
區域 |
|
說明 | 在 FIDL 繫結中加入追蹤事件,可在 Fuchsia 上跨越程序啟用端對端流程,而無需手動設定自訂 ID。 |
作者 | |
提交日期 (年-月-日) | 2019-02-28 |
審查日期 (年-月-日) | 2019-02-28 |
拒絕理由
沒有回應的訊息 (無論是事件或立即執行後即忘記的呼叫) 的交易 ID 都會設為 0,因此無法使用建議的配置區分。
有些用途會利用 zx_channel_call(),該函式會在核心中指派交易 ID,並等待回覆。(這個模式可讓並行呼叫端依賴核心同步處理,避免使用者空間鎖定交易 ID 指派作業)。同樣地,建議的配置無法區分這些項目。
預期核心追蹤支援會提供這項審查所需的遙測資料,而且建議改善這項機制,而非在 FIDL 繫結中推送這項資料。
最後,由於 Fuchsia 廣泛使用 FIDL,因此在 SDK 依附元件優先順序中,使用 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),這些 ID 會與非加密雜湊值一起雜湊。
透過 zx 管道傳送 FIDL 的穩定追蹤 ID 範例
我們建議您結合幾個 ID:
- FDK FIDL 的伺服器端 koid,可透過 zx_object_get_info() 取得,主題為
ZX_INFO_HANDLE_BASIC
,使用伺服器端的 koid,以及用戶端的相關 koid; - 交易訊息的方法序號 (注意:這目前是 uint32 雜湊值,很快就會演進為 uint64 雜湊值,請參閱 RFC-0029)。
- 最後,交易訊息的交易 ID。
這三個 ID 的組合方式應盡量減少可能發生的追蹤 ID 衝突,優先順序如下:
- 兩個不同訊息之間 (相同的序號),以及相同的用戶端和伺服器之間。
- 兩個不同訊息之間 (不同序號),以及相同用戶端和伺服器之間;
- 兩個不同訊息之間 (不同序號),以及不同用戶端和伺服器之間。
目前,koid 指派作業大多是依序進行。因此,koid 的最低位元會比最高位元擁有更多熵。同樣地,系統會依序指派交易 ID,因此在最低位元中提供更多隨機性。方法序號會以密碼編譯方式進行雜湊,雖然最高位元會保留給系統使用,但可以安全地假設所有位元都具有相同的熵。
因此,在目前條件下,合理的演算法為 OR:
koid & OxFFFF << 48
ordinal & 0xFFFFFFFF << 16
transaction ID & 0xFF << 0
在 FIDL 繫結的接收端,也會啟動追蹤時間長度。在 C++/Rust 等語言中,這會使用 RAII 設定範圍,並允許將事件與其他流程事件拼接。
人體工學
這麼做可讓追蹤系統更容易使用,對基礎架構也是一大福音。
說明文件和範例
應更新說明文件,說明如何新增追蹤記錄 (如上所述)。
回溯相容性
這項變更與 API 和 ABI 相容。
成效
停用追蹤類別時,這項操作的成本很低,每個 dje@google.com 測試的成本不到 5 奈秒 (在 NUC 上)。我們也可以在需要更高效能時,從 IR 中移除追蹤註解。
安全性
不會影響安全性。
缺點、替代方案和未知事項
替代方案
核心追蹤機制
在管道讀取和管道寫入作業中,利用現有的 ktrace 流程事件。
在沒有這項功能的情況下,您可以嘗試在基礎管道的讀取和寫入作業中使用現有的 ktrace 流量事件來完成這項作業。不過,這並非理想做法,因為通道適用於所有 FIDL 介面,也就是說,您只能指定一個類別。也就是說,使用者必須啟用管道讀取和管道寫入類別,才能實際使用,這表示所有管道讀取和寫入事件 (而非僅用於所需 FIDL 介面的事件) 都會出現。這會導致追蹤檢視器輸出內容難以讀取、不必要的 ktrace 緩衝區使用情形,並且會依賴 FIDL 實作詳細資料。