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

RFC-0218：IOBuffer：高效率 IO 的對等互連共用記憶體物件
狀態已接受
區域
  • 核心
  • 系統
說明

推出新的共用記憶體物件，以改善分散式 IO 使用案例。
問題
變更
作者
審查人員
提交日期 (年/月)2022-09-29
審查日期 (年/月)2023-05-09

編輯此 RFC

編輯 RFC 中繼資料

摘要

我們提議採用全新的 IOBuffer 核心基本功能，改善通訊與分散式 IO 用途的安全性、便利性與效能，同時採用共用記憶體和選用的核心中介作業。

提振精神

大部分 Fuchsia 作業系統是在使用者空間中實作，分散在多個通訊程序和元件之間。這種刻意設計的設計方式通常比單體系統中對等的實作多出更多程序和執行緒，尤其是在單體核心中直接實作對等的功能時。雖然這種分散式方法在安全性、開發和可更新方面具有顯著優勢，但重要的影響是，如果單體核心中只需要系統呼叫和狀態讀取/寫入，許多作業都需要 Fuchsia 中的 IPC。此外，使用現有 Fuchsia 管道和通訊端基元的處理序間通訊 (IPC) 作業涉及多個系統呼叫、模式交換、執行緒躍點和資料副本，以完成端對端作業。這種負擔的影響可能會大幅影響通訊和 IO 工作負載，特別是處理大量資料、高頻率和/或低延遲作業的情況。

原則上，共用記憶體可避免部分或所有負載，同時維持 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 效能、診斷和 Zircon Performance Tools WG 的設計審核與疊代。

設計

IOBuffer (IOB) 設計導入了新型記憶體物件，可提升通訊效率和分散式 IO。新物件將具有不同屬性和角色的多個記憶體區域封裝為單一的連貫實體，並提供實用的生命週期管理、存取權控管和核心中介作業。

IOB 是具有兩個端點的對等互連物件組合。端點提供生命週期管理和信號與其他對等互連物件類似，例如管道、通訊端、局部和事件組合。除了一般端點處理權利所提供的存取權控管之外，您亦可針對每個記憶體區域個別設定存取權，以便支援精細的安全性屬性。

即使是更強大的安全性屬性，也能由可設定的核心中介作業支援，也就是透過核心系統呼叫代表使用者執行記憶體存取作業，而核心的工作為一律遵循要求的存取規則。中介服務作業會為了維護健全性和安全性，而產生一些負載，同時維持較低的端對端負擔，低於其他通訊基元。

相較於透過其他獨立物件組合而成的類似結構，這種彈性的生命週期管理、記憶體區域封裝、可設定的存取權控管機制，以及核心中介作業支援多種共用記憶體通訊和 IO 模式，提升安全性和便利性。

目標

此提案具有下列概略目標：

  • 減少記憶體配置、系統呼叫、排程通訊和 I/O 作業負擔，縮小單體系統的效能缺口。
  • 簡化共用記憶體生命週期的管理和同步處理作業。
  • 視需要強制執行高強度的安全性變化。
  • 為日後的核心和使用者介面介面提供基礎。

端點

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

記憶體區域

IOB 包含一或多個記憶體區域的集合，這些區域具有獨立屬性和存取權控管，可支援通訊協定中的各區域預期角色。例如，不同區域可能會用於鍵/值存放區、用戶端協調、狀態管理和資料酬載傳輸等目的。

存取權控管

在 IOB 建立期間，系統會為每個端點和區域組合設定記憶體存取權。每個端點都有不同的存取權。驗證作業時，地區存取權控管機制會與端點的處理權限結合。作業的有效權利可能比處理權限還嚴格，但不得大於控點權利許可。

記憶體存取權也可以透過核心中介服務，不需要對應。

下表為與地區相關的三種存取權控管類型。每個區域的對應 (使用者) 和中介 (核心) 存取權控管機制可獨立設定，而端點權限則來自啟動作業的控制代碼。

類型 第 0 集 第 1 集
對應 (使用者) uR0、uW0 uR1、uW1
中介 (核心) kR0、kW0 kR1、kW1
端點 (帳號代碼) hR0、hW0 hR1、hW1

透過端點 Epn 進行對應或中介作業的有效存取權 (eRn 和 eWn) 計算方式如下：

作業 讀取權限 (eRn) 寫入權限 (eWn)
地圖 uRn 和 HRn uWn & hWn
中介服務運算 kRn & HRn kWn & HWn

中介存取權控管與方向

使用者和核心存取權控管的細微差異，是先前的控制項讀取或寫入存取權具有絕對性，而後者在邏輯或方向上運作。舉例來說，核心中介讀取作業可能會更新區域中的簿記資料結構，指出從緩衝區讀取的資料量。在此情況下，唯讀存取權並不會禁止核心更新簿記設定，而是指出僅允許邏輯讀取作業和相關的簿記更新。

範例

以下結構定義圖表呈現了 IOB 具有三個記憶體區域，其中包含邏輯函式。系統會在邏輯上將端點 Ep0 和 Ep1 分別指派給伺服器和用戶端角色。

  1. 區域 0「控制」：
    • Ep0：RW 對應存取權。
    • 第 1 集：RO 對應存取權。
    • 用途：伺服器會寫入這個區域中的不可部分變數，以便將狀態發布至用戶端，並協調用戶端的活動。
  2. 區域 1「字串對應」：
    • Ep0：RO 對應存取權。
    • 第 1 集：中介服務 WO 存取權。
    • 用途：用戶端使用核心中介作業將字串內部化，透過對應作業，伺服器可將其解譯為不受鎖定。由於用戶端存取權僅採用中介存取，因此除了新增項目外，用戶端不得竄改字串對應，藉此減少可能的檢查時間和伺服器風險。
  3. 區域 2「資料環狀緩衝區」：
    • Ep0：RW 對應存取權。
    • Ep1：RW 對應存取權。
    • 用途：用戶端和伺服器都會透過使用協議的通訊協定，直接存取這個區域，並接受潛在的完整性問題。

基本 IO 環場緩衝區

建立時間

IOB 是透過呼叫 zx_iob_create 並設定一組選項來建立。

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：指定區域陣列中的元素數量。

  • 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 會指定支援區域和後端的記憶體物件類型。

  • access：指定每個端點的存取權控管修飾符。記憶體存取子係可能會指定哪些存取位元組合適用於安全性或正確性屬性。

    • 位元 0：Ep0 的 uR0 對應。
    • 位元 1：Ep0 的 uW0 對應。可能暗示有些系統使用 uR0。
    • Bit 2：Ep0 透過 kR0 中介服務存取權。
    • 位元 3：kW0 透過中介服務為 Ep0 存取資源。
    • 位元 4：Ep1 的 uR1 對應。
    • 位元 5：Ep1 的 uW1 對應。可能在部分系統上可能暗指 uR1。
    • 位元 6：Ep1 的 kR1 存取中介服務。
    • 位元 7：Kp1 的中介服務存取權。
    • [8..31]：保留供日後使用。

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

  • tuipline 會指定核心中介作業要採用的記憶體存取領域。

區域類型 0：私人

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

struct zx_iob_region_private_t {
  uint64_t options;
};
  • options。
區域類型 1+：保留供日後使用

未來的擴充功能可能包含共用區域類型，讓多個 IOB 共用相同的記憶體物件，以便支援高效率的多代理程式協調作業。

對應

IOB 的記憶體區域會透過呼叫 zx_vmar_map_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 的控制代碼。
  • 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 是會傳回對應虛擬地址的外參數。

支援選項：

  • 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 區域說明元素的陣列。

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 區域的記憶體物件與一般 VMO 分開計算，包括控制代碼和對應項目的可達性。

針對私人區域類型，備份記憶體物件會獲派不同的 KOID，而且根據預設，會與擁有的 IOB 共用相同的名稱。存取權學科可能會覆寫或修改私人區域的預設名稱。

中介服務存取權

IOB 支援可設定的核心中介服務存取記憶體區域。相較於透過直接存取，將核心當做受信任的中介機構，這種存取方式可提供更加嚴格的資料完整性及其他不變性存取權。核心保證遵循存取區針對記憶體區域指定的存取規則。

透過中介服務、寫入和新增等多種方式

中介服務作業是由 IOB 讀取、寫入和輔助系統呼叫執行，以便在日後的擴充功能中指定。如果使用情況在語意上保持一致，存取範圍可以定義新的 IOB 系統呼叫，或超載先前定義的此類呼叫。一般目標是定義幾個適合多種用途的可重複使用 Syscall。

權限

根據預設，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 等低層級設施的檢測。
  • 同時使用 RFC 0181：無鎖定可捨棄的 VMO 時，允許核心安全地收回追蹤事件緩衝區，藉此提升可靠度。

系統追蹤 IOB 可能會使用如下所示的設定：

  • 角色：
    • Ep0：追蹤記錄管理員
    • 第 1 集：追蹤提供者
  • 區域 0：追蹤類別位元向量
    • 類型：私人
    • 存取：
    • Ep0：uR0、uW0 (R/W)
    • 第 1 集：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)
    • 第 1 集：uR1、uW1 (R/W)
    • 重點：未來多重生產者/單一消費者的環形緩衝區模式。
    • 用途：適用於低速率 / 靜態追蹤事件 (例如執行緒名稱) 的無鎖定環形緩衝區。一般需要這些事件才能正確解讀高頻率緩衝區中的其他追蹤事件。
  • 區域 4：高頻率追蹤事件
    • 類型：私人
    • 存取：
    • Ep0：uR0、uW0 (R/W)
    • 第 1 集：uR1、uW1 (R/W)
    • 重點：未來多重生產者/單一消費者的環形緩衝區模式。
    • 用途：適用於高頻率追蹤事件的無鎖定環場緩衝區。可在循環緩衝區模式下遺失資料。

系統記錄

IOB 透過支援下列項目，提供建立更安全、更有效率的系統記錄的基礎：

  • 區隔不同元件和/或嚴重性層級的記錄，防止跨元件和跨嚴重性記錄滾動。
  • 避免處理未主動觀察到的記錄。
  • 避免使用調度執行緒來處理嚴重性變更。
  • 個別元件 (記憶體) 的資源管理與可靠度。

涉及以下行為者：

  1. 記錄檔產生者：發出記錄的元件。
  2. 記錄檔管理員 (Archivist)：將所有生產端的記錄轉送至所有消費者。
  3. 記錄用戶端：連線至記錄管理員，並讀取合併的記錄檔串流。

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

  • 角色：
    • Ep0：記錄檔管理員 (架構師)
    • Ep1：記錄檔製作者 (部分元件)
  • 區域 0：控制
    • 類型：私人
    • 存取：
    • Ep0：uR0、uW0 (R/W)
    • 第 1 集：uR1 (RO)
    • 學科：無
    • 用途：儲存執行階段設定，例如最低嚴重性。視記憶體管理需求而定，可能也會儲存記錄環形緩衝區大小上限的相關資訊。
  • 區域 1：字串表格
    • 類型：私人
    • 存取：
    • 第 0 集：uR0 (RO)
    • Ep1：kW1 (WO)
    • 項目：未來的 ID/blob 分配器學科。
    • 用途：依序 ID/字串對應，代表內部化字串，用於經常參照的記錄字串、標記、鍵、中繼資料。
  • 區域 2：記錄環形緩衝區
    • 類型：私人
    • 存取：
    • Ep0：uR0、uW0 (R/W) (寫入 R/W/C 指標，以及寫入傳輸中計數器)
    • Ep1：kW1 (WO)
    • 重點：未來多重生產者/單一消費者的環形緩衝區模式。
    • 用途：用於記錄記錄的無鎖定環形緩衝區。容許在循環緩衝區模式下遺失資料。我們打算從生產端提供核心修飾寫入開始，並從管理員直接讀取資料。如果效能需要，則可能會改為供生產端直接存取。

實作步驟

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

  1. 在 @next 屬性底下導入 IOB 介面：
    • 實作基礎 IOB 調度工具。
    • 實作 syscall 和常見驗證。
  2. 分支版本，提供以 IOB 為基礎的追蹤和記錄原型，以及必要的 IOB 擴充功能。
  3. 針對必要的擴充功能編寫及修飾 RFC。
  4. 導入擴充功能並移除 @next 屬性。
  5. 針對 IOB 建立追蹤和記錄，並以軟性傳輸現有用戶端的方式傳遞至新介面。

效能

在淘汰及移除目前追蹤/記錄實作之前，系統會比較端對端延遲時間和相似作業的負擔，藉此驗證效能改善程度。持續的基準測試可能包含緩衝區記憶體來源 (VM 負擔)、金鑰作業的延遲/並行測試，以及分配測試狀態，以便驗證穩定的記憶體用量屬性。

人體工學

IOB 在設計上比類似功能所需的 VMO、事件和處理序間通訊 (IPC) 物件組合起來更容易理解。比起 VMO，對多個物件的組合來說，IOB 端點的生命週期也比較容易管理。與記憶體存取相關規則比較容易強制執行。

回溯相容性

IOB 會在語言引入新的控制類型，從而影響 FIDL 檔案來源相容性和 ABI 傳輸格式相容性，這不會影響回溯相容性。

安全性考量

共用記憶體用途一律有一些潛在的安全安全漏洞。大多數 IOB 使用不會引致共用 VMO 不受規範的新危害。不過，IOB 可以降低某些錯誤的風險，因為我們對權限和記憶體存取生命週期的規範較嚴格。

將情境和檢查時間複製到使用時間的危險項目

共用記憶體用途中潛藏著一項重要的軟體錯誤，稱為「檢查時間來檢查時間」(TOCTOU)。如果在檢查某些狀態及使用檢查結果之間出現競爭狀況，會導致狀態在檢查和使用結果之間變成無效，因而引發 TOCTOU 危險。

要避免在開放式共用記憶體用途中造成 TOCTOU 危險，通常需要從共用記憶體區域中複製資料，以避免在驗證期間或之後進行修改。即使已採用複製機制，請務必小心避免複製，因為除非使用特定介入措施，否則編譯器可能會最佳化複本，並直接在共用記憶體區域中運作。

核心中介作業可確保核心遵守中繼資料更新、酬載傳輸和存取記憶體順序的規則，藉此簡化減輕 TOCTOU 的危害。例如，使用環形緩衝區區時，核心在消費者確認之前，必須先更新環形緩衝區簿記，才能覆寫記錄內容，避免在驗證之前先複製酬載。

儘管如此，使用者仍必須負責正確套用記憶體順序和原子，或語言特定等項目，以避免因最佳化作業而造成正確性危害。為減輕使用者的負擔，Fuchsia SDK 會包含支援語言的程式庫，這些程式庫會針對每個已定義的學科執行正確的存取處理常式。學科規格還包含足夠的詳細資料，可以安全正確套用存取規則。

隱私權注意事項

除了目前已適用於處理序間通訊 (IPC) 和共用記憶體用途的新考量外，IOB 也不會引進新的隱私權注意事項。系統事件追蹤和記錄的初始用途將繼續履行相同的隱私權義務。

測試

測試包括下列項目：

  • IOB 的核心測試。
  • 針對新類型，處理類型驗證的 FIDL 一致性測試。
  • 擴大 Fuchsia 追蹤系統測試，以納入 IOB 專屬功能。
  • 擴充系統記錄測試，納入 IOB 專屬功能。

現有不依賴基礎實作詳細資料的追蹤和記錄測試應能繼續正常運作及通過。

說明文件

說明文件更新包括：

  • Syscall 參照。
  • 核心概念。
  • FIDL 帳號代碼類型。

缺點、替代方案和未知

這項提案的實作成本相對較低，因為該功能是在現有機器上建構，用於虛擬記憶體和對等互連調度工具。這項專屬功能以非對稱存取權、核心中介服務區域存取權，以及未對應的關閉功能為中心。

先前的圖片和參考資料