RFC-0218：IOBuffer：適合有效率的 IO 共用記憶體物件

摘要

我們建議使用新的 IOBuffer 核心原始碼，藉此改善通訊和分散式 I/O 用途的安全性、便利性和效能，並使用共用記憶體和選用的核心中介作業。

提振精神

大部分的 Fuchsia 作業系統是在使用者空間中實作，並分散至多個通訊程序和元件。這種刻意設計的選擇通常會比單體系統中的同等實作項目需要更多程序和執行緒，尤其是當同等功能直接在單體核心中實作時。雖然這種分散式方法在安全性、開發和更新可行性方面具有重大優勢，但重要的影響是，在單體核心中只需要系統呼叫和狀態讀取/寫入時，許多作業都需要在 Fuchsia 中使用 IPC。此外，使用現有 Fuchsia 管道和 Socket 原始碼的 IPC 會涉及多個系統呼叫、模式切換、執行緒跳轉和資料複製，以完成端對端作業。這類額外負擔對通訊和 I/O 工作負載的影響可能相當大，尤其是涉及大量資料量、高頻率和/或低延遲作業的情況。

原則上，您可以使用共用記憶體來避免部分或全部的這類額外負擔，同時保留 Fuchsia 使用者空間隔離模型的優點。不過，原始共用記憶體有其限制，因此在許多情況下，要進行安全、有效率且可靠的通訊相當困難，尤其是涉及多個用戶端、信任或可靠程度不一，或共用資源的情況。

其中一些挑戰包括：

• 安全性和正確性：直接存取共用記憶體通訊模式很難在沒有重大負擔或重大複雜性的情況下，對濫用或濫用行為做出回應。重要的是，系統呼叫比任意記憶體存取更容易驗證。
• 同步處理：直接記憶體存取可提供超出架構記憶體模型的有限同步處理機制。
• 生命週期和工作階段：記憶體存取範圍很難透過現有原始元素推理及強制執行。

這項提案是解決這些問題和其他挑戰的務實做法，可利用 Zircon 對等物件模型改善工作階段管理，並將核心用作可信任的中介來強制執行義務。

相關人員

協助人員：

• cpu@google.com

審查者：

• adanis@google.com
• rashaeqbal@google.com
• fmeawad@google.com
• gmtr@google.com
• maniscalco@google.com
• johngro@google.com
• abarth@google.com
• cpu@google.com

諮詢：

• miguelfrde@google.com
• puneetha@google.com
• mseaborn@google.com
• mcgrathr@google.com
• quiche@google.com
• mvanotti@google.com
• brunodalbo@google.com

社會化：

這項 RFC 已通過設計審查，並與 Fuchsia Performance、Diagnostics 和 Zircon Performance Tools WG 進行迭代。

設計

IOBuffer (IOB) 設計引進了新類型的記憶體物件，可用於進行有效的通訊和分散式 I/O。新物件會將具有不同屬性和角色的多個記憶體區域封裝為單一一致的實體，並提供實用的生命週期管理、存取控制和核心中介作業。

IOB 是具有兩個端點的對等物件組合。端點提供與其他對等物件 (例如管道、Socket、FIFO 和事件組合) 類似的生命週期管理和訊號傳送功能。除了一般端點句柄權限提供的存取控制項外，您還可以針對每個端點個別設定各記憶體區域的存取權，以支援精細的安全性資源。

可設定的核心中介運算可支援更強大的安全性屬性，在這種情況下，系統會透過核心系統呼叫代表使用者執行記憶體存取作業，核心會扮演可信任的中介角色，一律遵循要求的存取規則。中介運算可為您帶來穩定性和安全性，但會產生一些額外負擔，不過與其他通訊基本元素相比，中介運算的端對端額外負擔較低。

這項靈活的組合包含生命週期管理、記憶體區域封裝、可設定的存取控制項，以及核心中介作業，可支援各種共用記憶體通訊和 I/O 模式，相較於由其他獨立物件組成的類似結構，這項組合可提供更高的安全性和便利性。

目標

本提案有下列高階目標：

• 減少記憶體配置、系統呼叫，以及通訊和 I/O 的排程負擔，縮小與單體系統的效能差距。
• 簡化共用記憶體的生命週期管理和同步處理作業。
• 視需要強制實施強大安全不變量。
• 為日後的核心和使用者空間介面提供基礎。

端點

每個 IOB 都有兩個端點：Ep0 和 Ep1。IOB 端點句柄可能會重複，並由多個程序共用。只要存在至少一個端點句柄，IOB 就會保留基礎記憶體物件，為其他對等物件提供類似的生命週期語意。

記憶體區

IOB 會封裝一或多個記憶體區域的集合，這些記憶體區域具有獨立的屬性和存取控制項，可支援各區域在通訊通訊協定中的預期角色。舉例來說，您可以使用不同的區域來執行鍵/值儲存、用戶端協調、狀態管理和資料酬載轉移等作業。

存取權控管

在建立 IOB 時，系統會為每個端點和區域組合設定記憶體存取權。每個端點可能會獲得各個區域的不同存取權。驗證作業時，區域存取權控管機制會與端點的句柄權限結合。作業的有效權限可能比句柄權限更嚴格，但不得超過句柄權限允許的範圍。

記憶體存取作業也可以透過核心進行，而無需進行對應。

下表列出與區域相關的三種存取控制選項。每個區域可以獨立設定對應 (使用者) 和中介 (核心) 存取控制項，而端點權限則來自啟動作業的句柄。

針對端點 Epn 的對應或中介作業，有效存取權 eRn 和 eWn 的計算方式如下：

中介存取權控管和方向性

使用者和核心存取控制之間的微妙差異在於，前者會以絕對方式控制讀取或寫入存取權，而後者則會以邏輯或方向性方式運作。舉例來說，核心介面的讀取作業可能會更新區域中的記帳資料結構，以指出從緩衝區讀取了多少資料。在這個意義上，唯讀存取權並不會阻止核心更新記錄，而是表示系統只允許邏輯讀取作業和相關記錄更新。

範例

下圖為示意圖，顯示具有三個記憶體區域和邏輯函式的 IOB。Ep0 和 Ep1 端點分別在邏輯上指派給伺服器和用戶端角色。

1. 區域 0「Control」：
   • Ep0：RW 對應存取權。
   • 第 1 集：RO 對應存取權。
   • 用途：伺服器會在這個區域中寫入原子變數，以便將狀態發布給用戶端，並協調用戶端的活動。
2. 區域 1「字串對應」：
   • Ep0：RO 對應存取權。
   • 第 1 集：中介 WO 存取權。
   • 用法：用戶端會使用核心中介作業將字串內部化，並由伺服器使用對應項目解讀，不需鎖定。由於用戶端存取權僅限於中介服務，因此用戶端除了新增新項目之外，不得竄改字串對應項目，以免對伺服器造成潛在的檢查時間和使用時間危險。
3. 區域 2「資料環形緩衝區」：
   • Ep0：RW 對應存取權。
   • 第 1 集：RW 對應存取權。
   • 用途：用戶端和伺服器都會透過對應項目直接存取這個區域，並使用已同意的通訊協定接受潛在的完整性問題。

創作

您可以透過呼叫 zx_iob_create 和一組選項來建立 IOB。

zx_status_t zx_iob_create(uint64_t options,
                          const zx_iob_region_t* regions,
                          uint32_t region_count,
                          zx_handle_t* ep0_out,
                          zx_handle_t* ep1_out);

參數

• options 是保留給日後擴充功能使用的。

• regions 是指向 zx_iob_region_t 區域說明陣列的指標。

• region_count 會指定 regions 陣列中的元素數量。

• ep0_out、ep1_out 是 IOB 端點的初始句柄的出參數。

區域說明

區域的幾何形狀和設定是由 zx_iob_region_t 區域描述結構定義。基本結構包含所有區域類型通用的欄位。

struct zx_iob_region_t {
  uint32_t type;
  uint32_t access;
  uint64_t size;
  zx_iob_discipline_t discipline;
  union {
    zx_iob_region_private_t private_region;
    uint8_t max_extension[4 * 8];
  };
};

• type 會指定區域的類型，以及支援該區域的記憶體物件。

  • 輸入 0：私人區域。
  • 類型 1+：保留供日後使用。

• access 可指定每個端點的存取權控管修飾符。記憶體存取規則可指定哪些存取位元組合有效，以支援安全性或正確性屬性。

  • 位元 0：Ep0 的 uR0 對應。
  • 位元 1：Ep0 的 uW0 對應。在某些系統上可能會表示 uR0。
  • 位元 2：Ep0 的 kR0 中介存取。
  • 位元 3：Ep0 的 kW0 中介存取。
  • 位元 4：Ep1 的 uR1 對應。
  • 位元 5：Ep1 的 uW1 對應。可能表示部分系統的 uR1。
  • 位元 6：Ep1 的 kR1 中介存取。
  • 位元 7：Ep1 的 kW1 中介存取權。
  • [8..31]：保留供日後使用。

• size 是區域的大小 (以位元組為單位)。大小會四捨五入至系統頁面大小邊界。使用 zx_object_get_info 搭配主題 ZX_INFO_IOB_REGIONS，即可判斷區域的實際大小。

• discipline 會指定要為核心介接作業採用的記憶體存取紀律。

區域類型 0：私人

指定由 IOB 專屬的私人記憶體物件所支援的區域。這個記憶體物件只能透過擁有的 IOB 作業和對應作業存取。

struct zx_iob_region_private_t {
  uint64_t options;
};

• 選項：保留供日後使用。

區域類型 1+：保留供日後使用

日後的擴充功能可能會包含共用區域類型，其中同一個記憶體物件會由多個 IOB 共用，以便支援有效的多代理程協調作業。

對應

呼叫 zx_vmar_map_iob 即可對應 IOB 的記憶體區域。這個呼叫的語意與 zx_vmar_map 相似。

zx_status_t zx_vmar_map_iob(zx_handle_t vmar,
                            zx_vm_option_t options,
                            size_t vmar_offset,
                            zx_handle_t ep,
                            uint32_t region_index,
                            uint64_t region_offset,
                            size_t region_len,
                            zx_vaddr_t* addr_out);

參數

• vmar 是 VMAR 的控制代碼，用於將區域對應至該 VMAR。
• options 等同於 zx_vmar_map 的 options 參數。系統僅支援下列選項。
• vmar_offset 等同於 zx_vmar_map 的 vmar_offset 參數。
• ep 是包含要對應的區域的端點。
• region_index 是對應記憶體區域的索引。
• region_offset 等同於 zx_vmar_map 的 vmo_offset 參數。
• region_len 等同於 zx_vmar_map 的 len 參數。
• addr_out 是傳回對應項目虛擬位址的 out 參數。

支援的選項：

• ZX_VM_SPECIFIC
• ZX_VM_SPECIFIC_OVERWRITE
• ZX_VM_OFFSET_IS_UPPER_LIMIT
• ZX_VM_PERM_READ
• ZX_VM_PERM_WRITE
• ZX_VM_MAP_RANGE

其他選項保留供日後使用，並在指定時傳回 ZX_ERR_INVALID_ARGS。

對應私人區域的功能與對應無法調整大小的 VMO 相同。如果對應項目超出記憶體物件的結尾，且未設定 ZX_VM_ALLOW_FAULTS，則會傳回 ZX_ERR_BUFFER_TOO_SMALL。

region_offset 和 region_len 參數是繪製地圖 API 的最佳做法。這項最佳做法的動機包括：

• 支援攔截對應呼叫的清理程式。使用明確的範圍，可簡化對已對應區域的追蹤。
• 支援明確管理位址空間放置和區域覆寫的沙箱功能。
• 更廣泛來說，請避免在使用 ZX_VM_SPECIFIC_OVERWRITE 時發生意外衝突。

VMAR 作業

已對應的區域通常支援 VMAR 作業，例如 zx_vmar_protect、zx_vmar_op_range、zx_vmar_destroy。區域的存取規範可能會修改或限制這些作業，詳情請參閱規範規格說明。

物件資訊查詢

IOB 支援透過 zx_object_get_info 查詢物件屬性和記憶體區域。傳回的詳細資料包括各區域所支援的記憶體物件主要屬性，以便驗證和確保安全性。

主題 ZX_INFO_IOB

傳回整體 IOB 執行個體的相關資訊。

struct zx_iob_info_t {
  uint64_t options;
  uint32_t region_count;
  uint8_t padding1[4];
};

成員

• options 是傳遞至 zx_iob_create 的 options 參數值。
• region_count 是 IOB 中的區域數量。

主題 ZX_INFO_IOB_REGIONS

傳回 IOB 每個區域的資訊，做為 zx_iob_region_info_t region description 元素的陣列。

struct zx_iob_region_info_t {
  zx_iob_region_t region;
  zx_koid_t koid;
};

• region 是區域說明，可能會交換存取位元。
• koid 是基礎記憶體物件的 koid。

存取修飾符位元會互換，Ep0 存取位元會反映進行查詢的端點存取權，而 Ep1 位元會反映其他端點的存取權，因此即使不知道 Ep0 和 Ep1 是哪些句柄，也能判斷本機和遠端句柄的存取權。

主題 ZX_INFO_PROCESS_VMOS

為了與現有的記憶體歸屬機制保持一致，本主題會將支援 IOB 區域的記憶體物件視為一般 VMOs，包括透過句柄和對應方式的存取能力。

對於私人區域類型，系統會為基礎記憶體物件指派不同的 KOID，並在預設情況下與擁有的 IOB 共用相同名稱。存取規範可能會覆寫或修改私人區域的預設名稱。

中介存取

IOB 支援可設定的核心介面存取記憶體區域。透過使用核心做為可信任的中介，可提供比直接存取更嚴格的資料完整性和其他不變量，保證核心會遵循存取規範，為記憶體區域指定存取規則。

中介讀取、寫入等

中介作業會由 IOB 讀取、寫入和輔助系統呼叫執行，這些會在日後的擴充功能中指定。存取規則可定義新的 IOB 系統呼叫，或超載先前定義的系統呼叫，前提是使用方式在語意上一致。一般目標是定義幾個可重複使用的系統呼叫，以便用於多種用途。

權限

根據預設，IOB 具有下列權利：

• ZX_RIGHTS_BASIC = (ZX_RIGHT_TRANSFER | ZX_RIGHT_DUPLICATE | ZX_RIGHT_WAIT | ZX_RIGHT_INSPECT)
• ZX_RIGHTS_IO = (ZX_RIGHT_READ | ZX_RIGHT_WRITE)
• ZX_RIGHTS_PROPERTY
• ZX_RIGHTS_MAP
• ZX_RIGHTS_SIGNAL
• ZX_RIGHTS_SIGNAL_PEER

屬性

IOB 支援 ZX_PROP_NAME，可提供診斷和歸因資訊。

IOB 可能會支援區域存取規範定義的其他屬性。

訊號

IOB 支援同儕和使用者信號，可提醒使用者注意特定情況。日後的擴充功能可能會定義可設定的信號。

ZX_IOB_PEER_CLOSED

當對其他端點的最後參照項目釋放時，端點會觸發 ZX_IOB_PEER_CLOSED。端點的句柄和從端點建立的對應項目，在這個用途上都視為參照。

ZX_USER_SIGNAL_*

使用者可以舉起 ZX_USER_SIGNAL_* 表示有特殊情況。

核心介面的存取規範

為了促進中介作業，核心必須瞭解如何正確存取記憶體區域。區域記憶體存取的規則和設定稱為存取規範，可能包括：

• 記帳的位置和格式。
• 覆寫/失敗政策。
• 浮水印和逾時設定。
• 記憶體順序和柵欄要求。

違規事項說明

存取規範會使用可擴充的說明結構體指定，其中的 32 位元標頭會指定說明的類型和格式。

#define ZX_IOB_DISCIPLINE_TYPE_NONE (0)

struct zx_iob_discipline_t {
  uint32_t type;
  union {
    uint8_t max_extension[4 * 15];
  };
};

未來 RFC 中可能會定義的學科範例包括：

• 生產者 / 消費者環狀緩衝區
• ID / Blob 對應
• 鍵 / 值儲存庫
• 散布 / 收集記憶體複製
• 目錄項目快取

實作

初始導入作業是支援追蹤和記錄客戶的基礎步驟。以下是個案研究說明，說明定義的 IOB 功能動機，以及解決用途需求的潛在擴充功能。

系統事件追蹤

IOB 旨在支援下列功能，為更安全、更有效率的系統事件追蹤奠定基礎：

• 將工作階段協調、中繼資料和事件收集作業專門移至 IOB 區域，藉此減少執行階段的額外負擔，並在初始設定後，無需調度執行緒和管道 IPC。
• 透過移除 IOB 核心 API 以外的依附元件，啟用 FDIO 和 FIDL 等低階設施的檢測功能。
• 允許核心安全地回收追蹤事件緩衝區，藉此避免嚴重 OOM 情況，並搭配使用 RFC 0181：無鎖定可捨棄的 VMO，提升健全性。

系統追蹤 IOB 可能會使用以下設定：

• 角色：
  • Ep0：追蹤記錄管理工具
  • 第 1 集：追蹤提供者
• 區域 0：追蹤類別位元向量
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：uR1 (RO)
  • 違規事項：無
  • 用途：代表已啟用追蹤類別的 uint64_t 位元向量陣列。
• 區域 1：追蹤記錄類別
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：kW1 (僅限加入項目)
  • 規範：未來 ID/blob 配置器規範。
  • 用途：依序 ID/字串對應，代表追蹤供應器使用的每個追蹤類別的類別位元。
• 區域 2：內部字串
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：kW1 (僅限加入項目)
  • 規範：未來 ID/blob 配置器規範。
  • 用途：代表追蹤事件名稱和其他常見名稱的內部字串的序號 ID/字串對應項目。
• 區域 3：低費率 / 靜態中繼資料
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：uR1、uW1 (R/W)
  • 規範：未來的多產生者/單一消費者環狀緩衝區規範。
  • 用途：用於低速 / 靜態追蹤事件 (例如執行緒名稱) 的無鎖環狀緩衝區。這些事件通常需要正確解讀高速率緩衝區中的其他追蹤事件。
• 區域 4：追蹤記錄事件頻率過高
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：uR1、uW1 (R/W)
  • 規範：未來的多產生者/單一消費者環狀緩衝區規範。
  • 用途：用於高頻率追蹤事件的無鎖環形緩衝區。在循環緩衝區模式下，可容許資料遺失。

系統記錄

IOB 旨在支援下列功能，為更安全、更有效率的系統記錄奠定基礎：

• 將不同元件和/或嚴重程度的記錄檔隔離，避免跨元件和跨嚴重程度的記錄檔輪替。
• 避免處理未積極觀察的記錄。
• 停止使用調度執行緒來處理嚴重性變更。
• 個別元件 (記憶體) 資源管理和問責制。

涉及下列執行者：

1. 記錄產生器：發出記錄的元件。
2. 記錄管理員 (Archivist)：將來自所有供應者的記錄轉送至所有取用端。
3. 記錄使用者：連線至記錄管理工具，並讀取已合併的記錄串流。

系統記錄 IOB 可能會使用以下設定：

• 角色：
  • Ep0：記錄管理員 (Archivist)
  • 第 1 集：記錄產生器 (部分元件)
• 區域 0：控制
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W)
  • Ep1：uR1 (RO)
  • 違規事項：無
  • 用途：儲存執行階段設定，例如最低嚴重性。視記憶體管理需求而定，也可能儲存記錄循環緩衝區的大小上限資訊。
• 區域 1：字串表格
  • 類型：私人
  • 存取：
  • Ep0: uR0 (RO)
  • Ep1：kW1 (WO)
  • 規範：未來 ID/blob 配置器規範。
  • 用途：這個連續 ID/字串對應表代表經常參照的記錄字串、標記、鍵、中繼資料的內部字串。
• 區域 2：記錄循環緩衝區
  • 類型：私人
  • 存取：
  • Ep0：uR0、uW0 (R/W) (針對 R/W/C 指標寫入，並寫入傳輸中計數器)
  • Ep1：kW1 (WO)
  • 規範：未來的多產生者/單一消費者環狀緩衝區規範。
  • 用途：記錄記錄的無鎖環形緩衝區。在循環緩衝區模式中，可容許資料遺失。我們預計從核心介面的寫入作業開始，並直接讀取管理員的資料。如有需要，製作者可改為直接存取。

導入步驟

實作程序會遵循一系列開發步驟：

1. 在 @next 屬性下方引入 IOB 介面：
   • 實作基本 IOB 調度器。
   • 實作系統呼叫和常見驗證。
2. 以分支中的 IOB 為基礎，設計原型追蹤和記錄功能，以及必要的 IOB 擴充功能。
3. 為必要的擴充功能撰寫並核准 RFC。
4. 實作擴充功能並移除 @next 屬性。
5. 在 IOB 上重新設定追蹤和記錄，將現有用戶端軟性轉移至新介面。

成效

您可以比較可比較作業的端對端延遲時間和額外負擔，然後淘汰並移除目前的追蹤/記錄實作項目，藉此驗證效能改善情形。持續基準測試可能包括緩衝區記憶體來源 (VM 額外負擔)、關鍵作業的延遲/並行測試，以及分配測試，以驗證穩定狀態記憶體消耗屬性。

人體工學

設計上，與需要用來模擬類似功能的 VMOs、事件和 IPC 物件組合相比，IOB 更容易推理。相較於組合多個物件的情況，I/O 端點的生命週期更容易以一致的方式管理，而且記憶體存取規則也比 VMOs 更容易強制執行。

回溯相容性

IOB 只會影響 FIDL 檔案來源相容性和 ABI 匯出格式相容性，因為它會為語言引進新的句柄類型，而不會影響回溯相容性。

安全性考量

共用記憶體用途一向存在安全漏洞的風險。大多數 IOB 用途不會引入共用 VMOs 不受影響的新危險。不過，由於 IOB 的權限和記憶體存取生命週期規則更嚴格，因此確實可降低發生特定錯誤的風險。

將 Elision 和 Time-of-Check 複製到 Time-of-Use Hazards

在共用記憶體用途中，有一種重要的軟體錯誤類別稱為「檢查時間到使用時間」危險 (TOCTOU)。TOCTOU 危險是由於檢查某些狀態與使用檢查結果之間的競爭狀況，導致在檢查與使用結果之間，狀態可能變得無效。

在開放式共用記憶體用途中避免 TOCTOU 危險可能相當困難，通常需要將資料從共用記憶體區域複製出來，以免在驗證期間或之後遭到修改。即使使用複製功能，也必須小心避免複製省略，因為除非使用特定介入措施，否則編譯器可能會將副本最佳化，並直接在共用記憶體區域上運作。

核心介接作業可簡化 TOCTOU 危險的緩解方式，方法是保證核心會遵循中繼資料更新、酬載轉移和存取記憶體順序的規則。舉例來說，使用環狀緩衝區規則時，只要消費者透過更新環狀緩衝區記錄管理，確認安全無虞，核心就保證不會覆寫記錄內容，因此無須在驗證前複製酬載。

不過，使用者仍需負責正確應用記憶體順序和原子操作，或特定語言的等效項目，以免因最佳化而導致正確性危害。為減輕使用者的負擔，Fuchsia SDK 將納入支援語言的程式庫，為每個定義的領域實作正確的存取例程。規範規格也會提供足夠的詳細資訊，讓您正確且安全地套用存取權規則。

隱私權注意事項

除了適用於 IPC 和共用記憶體用途的隱私權考量外，IAB 不會引入新的隱私權考量。系統事件追蹤和記錄功能的初始用途將繼續承擔相同的隱私權義務。

測試

測試包括：

• IOB 的核心測試。
• 針對新類型的句柄類型驗證，進行 FIDL 相容性測試。
• 擴充 Fuchsia 追蹤系統測試，納入 IOB 專屬功能。
• 擴充系統記錄測試，納入 IOB 專屬功能。

現有的追蹤和記錄測試不依賴基礎實作詳細資料，因此應可繼續運作並通過測試。

說明文件

說明文件更新內容包括：

• Syscall 參照。
• 核心概念。
• FIDL 句柄類型。

缺點、替代方案和未知事項

這項提案的實作成本相對較低，因為這項功能是建立在現有的虛擬記憶體和對等調度器機制上。這項獨特的功能以不對稱存取權、核心介面區域存取權和關閉時解除對應的功能為主。

既有技術與參考資料

• Fuchsia 追蹤系統
• Fuchsia 追蹤記錄格式
• RFC 0181：無鎖定可捨棄的 VMO
• 實作無鎖定讀寫環狀緩衝區