RFC-0190：Syscall 的 FIDL 支援

RFC-0190：FIDL 支援 Syscall
狀態已接受
區域
  • FIDL
  • 核心
說明

擴充 FIDL 以支援 syscall 宣告，並以 FIDL 表示我們的真實資訊來源。
問題
  • 11,0021
變更
作者
審查人員
提交日期 (年/月)2022-07-08
審查日期 (年/月)2022-09-22

編輯此 RFC

編輯 RFC 中繼資料

摘要

系統呼叫 (例如「系統呼叫」) 代表 Fuchsia 的基礎平台介面 (Fuchsia Interface 定義語言 FIDL) 目前無法定義它們。然而，由於缺乏支援功能，往往會帶來比諷刺名稱更重要的結果。「自備執行階段」 (簡稱「自攜權」是我們的核心概念之一)，旨在促進 (及簡化) 使用任意應用程式架構和程式設計語言，在 Fuchsia 上進行開發。其中一個重要的一環，就是讓執行階段能在其外與使用者地系統完美互動；這項功能已由 FIDL 不受語言影響的處理序間通訊 (IPC) 架構充分提供。的確，FIDL 是 Fuchsia 用來實現 BYOR 的指定車輛。但是，啟用執行階段的方法遠遠無法與其他程序通訊。如要讓任何執行階段真正「執行」，就必須啟用這項功能，以便與核心通訊，也就是說，才能發出系統呼叫。FIDL 在運作上根本不足。

這個 RFC 會互相處理，使我們得以朝完全實現 BYOR 的路徑邁進。具體而言，討論主題包括

  • 擴充 FIDL 以便以「一類」方式對系統呼叫介面進行編碼並完整指定；
  • 讓後者符合正式模型，而 FIDL 和 syscall 介面本身所產生的結果
  • 包括 FIDL 語言繫結使用這些資訊的方式，以及會為使用者提供哪些新設施；
  • 系統呼叫介面和依賴此元件的工具進行維護，在維護時就能帶來實質的益處。

文件只是意圖陳述，而非完整的提案。我們希望能在找出較小的設計問題 (按照後續 RFC 中所述) 的過程中逐漸浮現，因此預留大量實驗時間，並在過程中仔細思考。我們在這裡找出想要的終點、實現這些目標的概略藍圖，以及過程中應遵循的原則與限制。

提振精神

//zircon/vdso 中其實已有系統呼叫 syscall 介面的 FIDL 表示法；這是 FIDL 程式庫 zx，我們從這裡開始稱為「v1 (FIDL) 表示法」。不過，此表示法並非第一類別，會提出大量嘗試解讀的特性，包括自訂註解的零散，以及關於特殊名稱和註解的頻外信號，以及假設會使用 C 類程式碼產生此類程式碼的框架。這樣的慣用方法已足夠讓 kazoo 只對一個後端進行解讀。根據目前的這些定義，kazoo 為核心和 vDSO (Rust 系統呼叫外國函式介面) 產生基礎邏輯 (即FFI) 包裝函式、適用於標準程式庫中執行階段的 Go syscall FFI 包裝函式，以及系統呼叫說明文件 Markdown 的章節。

因此，我們目前處於過渡狀態，一種表示系統呼叫具有嚴重載入的 syscall，但無法做為實際的 FIDL 使用 (除了今天匯出的一些基本列舉和類型別名外)，這對任何要解讀的工具都會造成維護負擔。雖然「我們已經開始執行 X，而現在已經完成一半」，但它肯定有同理心的動機，特別是在目前狀態受到以下痛苦的情況時。

然而，v1 FIDL 表示法僅佔可靠資料來源的一部分；其中包含系統呼叫定義，但對呈現到介面的資料類型是不完整的計算。資料來源的可靠來源 (重複程度相當大) 則位於一組 C 標頭 (也就是 <zircon/types.h>、<zircon/syscalls.h> 和 <zircon/syscalls.h> 及 <zircon/syscalls/*>) 的一組 C 標頭中 (亦即 Circon/syscalls.h> 以及 <zircon/syscalls/*>)，才能解讀 v1 表示法以及由 Circon/syscalls/*> 資料所定義的實際維護類型。

印尼盾的動機

介面演變和偏移

如果系統呼叫介面發生異動，也必須提供這項資訊的所有不同分支。這些分支包括

  • 語言專屬的系統呼叫包裝函式。
    • 我們針對 Rust 和 Go 提供了這些屬性。請注意，Rust 包裝函式是 Kazoo 導入的細薄 FFI 層之上的額外層，且為了使用更慣用語言而保持不變。
  • C 資料類型的特定語言類比。
    • 我們有針對 Rust 和 Go 分別提供這些項目。
  • 不會處理「發出」系統呼叫，而是需要系統呼叫介面進行抽象轉換的使用案例。
    • 我們的系統呼叫 Markdown 就是其中一例，fidlcat 的介面合成也是其中一例。

同時，Syscall 介面和分支維護者有一些必要程序，才能讓這些東西保持同步並避免發生偏移。具體來說，系統呼叫介面維護人員必須知道所有分支的位置並記得更新，而在缺少機器可讀取的列舉資訊時，必須明確知道每個系統呼叫的列舉位置。

如果 Syscall 介面已經完全以 IDL 編碼，則這些分支可以重塑為後端，能以程式輔助方式產生所需資訊 (這樣會因為憑證被撤銷為真分支)。在預計的後端中，沒有什麼特別複雜。穩定後，其「觸控」應該會遠低於狀態現狀，並會自動配合 syscall IDL 的大部分變更 (就像現今大多數 .fidl 檔案變更時，不需要更新任何特定後端) 進行調整。

客戶

如果只有 C 在檢視畫面中 (無論是在 C 標頭中，還是 v1 FIDL 表示法的 C 音譯拼字)，您就能輕鬆導入在 C 中易讀的系統呼叫簽章和類型定義，但很難以其他語言建立模型。值得注意的範例包括

  • 做為獨立指標和長度的緩衝區
    • 許多語言都有單一類型來代表緩衝區，因此可能無法以此方式分解。這類語言的繫結也需要進一步信號，才能將 (指標、長度) 組合解讀為合併的緩衝區，而非不相關的引數。
    • 如果緩衝區指標和長度在系統呼叫簽名中並未並排顯示 (與 zx_vmo_read() 的情況相同)，模擬會變得更加困難。
  • 未標記的聯集
    • C 聯集稱為「未標記聯集」，因為這代表的類型是非交集的類型，但沒有標準方法，無法判斷特定執行個體實際保留的類型 (即「標記」)。「標記聯集」在其他語言中更常見 (且實用)，較可能以單一概念的形式呈現。
    • 資料類型中大部分 (但非全部) C 聯集的例項都可以建立為標記聯集，因為它們會在結構中呈現，且欄位相鄰的欄位是函式。但是，與上述緩衝區情況類似，目前沒有信號指出兩者相關，且有非鄰近標記的範例。
  • 透過類型清除功能進行多工處理
    • 我們有許多 Sys 呼叫運用 void* 的純型性質，來有條件地接受或傳回不同類型的服務，且能對多個函式簽名進行多工處理。最佳範例為 zx_object_get_info(..., uint32_t topic, void* buffer, ...)，依 topic 而定，系統會將 buffer 解讀為任何數量的類型。因此，以非 C 的語言建立模型可能較為困難：特別，繫結需要更多信號來確切地將簽名參數化，並且可能必須仰賴非標準針對每個可能的例項產生單獨的函式。

這類 C 主義 在非 C 語言中代表 syscall 介面的寫法可能明顯複雜。反之，如果某種形式的 IDL 受限於多變態性 IDL，則該框架會側重或盡可能減少這類問題。

政策實施

我們也打算針對系統呼叫和資料類型執行多項政策。 有了 IDL 化之後，後端就能存取以機器可解釋的方式呈現這項資訊，而此時，強制執行政策的工具就能直接編寫及維護。

如要為部分資料類型政策命名範例，請考慮下列內容 (如在 C 中代表)，這取自我們在核心和使用者空間之間共用資料的方式：

  • 固定大小結構或模型的動態大小陣列
    • 如果要接受其他任何方法，就會使資料的共用和解讀更加複雜。
  • 無間接
    • 資料必須是完全可理解的 memcpy，且位於建構時不同的位址空間內；對來源位址空間中資料的編碼參照/指標可能會留置不順，並且呈現難以理解。(zx_iovec_t 代表例外狀況，我們特別處理)。
  • 沒有嵌入式帳號代碼
    • 版面配置內嵌的控點是用於忘記關閉該控點 (或隱含「借用」的處理) 的方案。
  • 沒有布林值欄位
    • bool 會在記憶體中佔用 8 位元，但只提供 1 筆資訊。為提高空間效率，建議您使用 位元欄位來傳達 1 位元。
    • Paranoia：C++ 標準允許未初始化的 bool 不為 true 或 false！

以 IDL 代表 FIDL 的動機

獨立 IDL 的先前課程

平台先前已導入非 FIDL IDL：Banjo，用於表示驅動程式公開的介面。但後來被認為這是一項失誤：確實會造成維護負擔超過其附加價值、驅動程式庫作者對於 FIDL 與 FIDL 之間的語法差異感到困惑，而且自然想要在 FIDL 與 Banjo 之間共用資料類型，並不容易。此後，Banjo 已淘汰，大規模投入心力改善 FIDL 供驅動程式庫使用，並在原地使用 FIDL。假設適用於 Syscall 規格的 IDL 具有足夠的動機，那麼預期該用途的新 ID 就很合理，也會遭遇同樣的陷阱。

繫結開發

FIDL 語言繫結仰賴處理序間訊息傳遞 (例如透過管道)，因此必須瞭解促進通訊的系統呼叫子集。具體來說，他們已經負責管理這些 sys 呼叫的 FFI 包裝函式。如果這些系統呼叫是以機器可讀的形式呈現，繫結就能更輕鬆地建構及維護 FFI 層；但如果能理解系統呼叫並非由 FIDL 衍生，則繫結會取得更多資訊，或最終解讀兩個不同的 IDL IR (中繼表示法)。

在資料類型方面，目前我們維護的程式庫並非 FIDL 語言繫結，但同時會預期互通性。也就是說，我們自然會預期這兩個方式的慣用方式大致相同，這樣程式碼就能輕鬆使用組合，而且不必考量不正確的拼字或樣式決策。如果是核心物件控點和「zx_status_t」，我們預期這些都是「一致」的表示。一般而言，系統會透過繫結明確使用資料類型程式庫來完成這項操作，而這正是目前執行的工作。因此，這些內容單獨呈現在多數情況下是虛假自由，而這也一定會讓繫結維護者和使用者受益於相同位置 (詳情請參閱下方)。

多語化

FIDL 會根據與 BYOR 的關係，致力使用恰當對應到任何可能目標語言的抽象化機制。這個框架可以防止系統意外將系統呼叫介面調整為特定語言 (例如C)。

平台版本管理

FIDL 內建平台版本管理支援，可以簡化 syscall 的演進，以媲美其餘 FIDL 的方式，有效地簡化軟轉換。

相關人員

講師：

hjfreyer@google.com

審查者：

abarth@google.com, brettw@google.com, mcgrathr@google.com, surajmalhotra@google.com

顧問：

azaslavsky@google.com、bprosnitz@google.com、mcgrathr@google.com、yifeit@google.com

社群媒體化：

這個 RFC 中的高階提案皆已與 FIDL 和核心/vDSO 維護者保持社交狀態。

設計

如上所述，這份文件並未提供適當的設計。因此，我們會改為提出設計目標、原則和限制，以期進行統合。

目標

FIDL 程式庫 zx 是系統呼叫的唯一可靠來源

這份 RFC 中的許多問題都涉及競爭可靠資料來源的競爭來源，例如系統呼叫的形狀、定義和說明文件。我們的目標是確保所有系統呼叫資訊皆直接由單一可靠資料來源的直線機器翻譯，直接位於下游。

FIDL 程式庫 zx 已匯出至 SDK

這是實現此 RFC 中 BYOR 模式的基本先決條件。在實現此目標之前，相關新設施僅供在該平台內工作的開發人員使用。

Syscall 規格使用純 FIDL

最後，雖然系統可能在過程中來回切換，因此應只使用 FIDL 語言規格中的功能定義系統呼叫介面。FIDL 後端不應需要架構外的資訊才能解讀，即使其位於 SDK 中也一樣；且其他 FIDL 程式碼應可免費匯入並使用其資料類型。

fidlc 會強制執行系統呼叫政策

這裡的「系統呼叫政策」是指任何構成「正確」系統呼叫宣告的檢查類型，這類檢查純粹只是 FIDL 表示法中呈現的資訊。我們在上方列出了部分政策 (在 C 詞彙中)。

系統應在編譯時間強制執行系統呼叫政策。fidlc 負責驗證系統呼叫宣告的語法是否正確，因此也將語意判斷為語意正確嗎？我們希望確保後者的驗證會在某個時間點發生，但如果您將後者延後到之後的任意驗證步驟會使工具整合變得複雜，而且會延遲執行失敗所需的時間，導致使用者體驗不佳。

Syscall 繫結

FIDL 語言後端應提供「syscall 繫結」，也就是以該後端其他繫結樣式呈現介面「慣用」的系統呼叫包裝函式。具體來說，這表示這些函式簽名含有程式庫 zx 資料類型，因為這些資料類型是以這些繫結表示。這樣可為任何使用者提供與核心的標準互通操作，同時解決將其他繫結和發出邏輯的系統呼叫發出邏輯時出錯的情形。

如果我們不提供 Syscall 繫結，則 zx 資料類型的冒險可匯入，因為一般 FIDL 將造成新的尷尬。假設某個 FIDL 用戶端從管道提取了「zx_port_packet_t」，現在想用它呼叫「zx_port_queue()」。如何達成這個目標？如果呼叫端可以存取以該封包類型現有繫結做為輸入的 syscall 包裝函式，這種情況相當複雜；不過，如果包裝函式的封包類型不同，就會增加翻譯的負擔。無論這個翻譯邏輯位於何處，都會有負面的使用者體驗，也會產生一些不尋常的依存元件。最好完全不使用翻譯， 相關程式碼在設計上也可以互通。

有鑑於特定核心物件周圍的系統呼叫介面具有性暗示的物件導向性質，Syscall 繫結自然也會被選擇為代表該核心物件的類別方法。不過，這與後端維護者無關。

Syscall 演進化技術，幾乎不需人工作業

目的是希望從 Syscall 進化，然後透過幾個簡單步驟 (至少最常見的步驟) 進入基本運作：

步驟 1：變更 FIDL 系統呼叫宣告，限制在平台 API 級別 X 中新增或移除；更新核心和 vDSO，以便跟進變更。

非步驟：不必費心更新任何後端 (例如產生 Markdown 生成的 fidldoc)，因為每個後端都會自動產生正確的 syscall 繫結。

步驟 2：針對每個「程式碼集」，將目標平台 API 級別提高至 >= X，並更新所含程式碼以使用新的系統呼叫繫結 (或者要求下游專案自行執行這項操作)。

可能的步驟 3：如果步驟 1 中有任何 syscall 宣告已經淘汰，因為支援的最低平台 API 級別 >= X 時，請返回並移除。

原則

盡可能使用一般 FIDL 公用程式

隨著新的類型、語法和語意問世，應優先考慮到 FIDL 的一般實用性，或至少仔細考量這點。需要一系列新功能，並具備與非系統呼叫相關用途的共同合作 (更確定實現)。重疊程度越高，系統呼叫宣告的內容就越容易。這可能也有助於您更加熟悉 FIDL 工具中的相關支援，進而減少維護。

針對系統呼叫資料類型導入的新宣告類型，應避免遵守 FIDL 語言限制，原因如下：

  • 如前所述，我們希望規格使用「純」的 FIDL，因此任何對這些新結構進行的任何重新劃分，都會無法顧及到這一點，但在實務上可能會如此；
  • 這些類型會由出現在程式庫 zx 中的每個語言後端大規模使用；
  • 其 zx 執行個體會以標準格式表示系統資訊，這類資訊應能自由地傳輸，傳輸到任何傳輸中；
  • 建立系統呼叫資料類型模型的相關問題，實際上並不是核心系統呼叫特定問題；一般而言，這類問題適用於記憶體格式建模，且可能擁有更寬廣的應用程式。
  • zx 資料類型是一個很好的區塊，其中使用了現今存在的基本無限制宣告；如果這些類型的任意子集對其使用情形造成極大限制，就會感到不解。

減輕翻譯負擔

系統呼叫宣告 IR 應盡可能簡單 (而且不更簡單)，且後端在理想情況下應能採用統一邏輯 (以最少的特殊大小寫形式進行解讀)。我們應盡可能讓無限的未來後端作者能夠以簡單的方式進行解讀，並減少必須瀏覽的銳角數量。

變更系統呼叫介面的意願

我們會盡可能嘗試模擬系統呼叫介面。不過，有些案例可能是難以建立模型在這類情況下，我們秉持盡量減少解釋負擔的原則，您應謹慎處理過度配適情形，並願意配合介面調整介面，以期有助於建立模型。

限制

持續忽略 vDSO 和核心的 FIDL 運作。

藉由「作業」，是指在系統呼叫簽名或實作注意事項中表達 FIDL 的知識。這種狀況不包含在實作 vDSO 和核心時，使用 FIDL 產生的程式碼 (之後仍然是巨大值)。

vDSO 的內部作業應保持不透明。我們嘗試建立其介面的模型，但這並非為模型提供對象提供知識，這並非不相關的工作。讓系統呼叫作業能實際偵測 FIDL，這可能就是導致這些系統各自存在的抽象違規行為，但至少是怪異的潛在客戶，因為在 FIDL 以外的環境仍然可能發出系統呼叫 (不用提及大型 Fuchsia)。而且可能會列出新的系統版本管理問題。Syscall 繫結只是用來在 FIDL 與 vDSO 世界之間搭起橋樑。他們可以自由向使用者顯示系統呼叫，做為與其他 FIDL 端點的通訊，但這是個別後端部分的前端選項。

完整規格

Syscall 規格應具有「完整」性質，用來對介面的完整語意進行編碼，且通常包含與系統呼叫相依的後端 (包括產生說明文件的後端) 所需的所有機器可讀資訊。

電線上的 Syscall 資料類型與 C 表示法相符

假設某人想要將記憶體格式編碼為 FIDL，這項考量包括但不限於 C vDSO API 預期的 syscall 參數，但也可能包含從註冊版面配置、網路封包標頭到 ZBI 格式的所有內容。此類資料的取用者自然會預期以定義格式使用，因此，如果想將其繫結轉回格式正確，FIDL 編碼就只會針對特定語言「可以使用」。語言繫結已針對 FIDL 中可定義的任何類型對 FIDL 傳輸格式進行編碼及解碼。如果該記憶體格式的特定位元版面配置與 FIDL 傳輸格式完全相符，然後在 FIDL 中描述每個版面配置，每個語言繫結都能支援該格式，而無須執行新的格式特定工作。

基本 FIDL 類型的傳輸格式與自然 C 類比 (而且不太可能改變) 的版面配置來說其實並沒有什麼特別的：目前這些類型是不可改變的原型和布林基元、列舉、位元、陣列和結構體。為求簡單起見，並為了提供系統呼叫繫結來轉譯預期 vDSO 輸入內容的標準方法，我們提議將資料類型的模型單獨限制為這些 FIDL 類型。特別是根據上述作業忽略限制，使用含有非行資料的類型，以及 FIDL 特定標頭。

向量代表在此案例中有趣的案例，也是可能的例外狀況。Syscall 可接受動態大小的資料陣列，作為緩衝區並另外提供長度的緩衝區。這種情況是根據向量繫結自然建模。不過，向量的線格式會指定為 (長度和指標)，系統呼叫則會預期緩衝區參數為 (指標、長度)。(前者的指標也包含 void* 類型，而後者可為特定類型的指標)。我們可以更新 Syscall 介面中的所有緩衝區參數，讓上述原則同樣適用於向量，但要將此情況視為定義例外狀況並不合理。而實際上，要在任何地方取用這些參數的工作量，是停滯且風險不高；這樣的好處是必須避免讓向量序列化以交換兩個參數，造成最低的認知負擔。(我們也有 zx_iovec_t，這是類似向量的類型)。

實作

  • 對於每項新功能，FIDL 和核心/vDSO 維護人員將會合作並產生 RFC。核准並實作功能之後，v1 表示法就會更新為使用。

  • v1 表示法的冪等性將合併到自動調整層，因此有更多後端可以寫入更多後端，忽略原本在 FIDL 中編碼的系統呼叫。有一個簡單的方法能達成這個目標，就是將 IR 轉換為近似於 fidlc 擴充語言後產生的最終 IR；這也可能是一個低風險的主觀，以漸進的方式判斷後 IR 的樣貌。隨著 v1 表示法更新為使用新的 FIDL 功能，自動調整層仍可在最終到刪除點終止。這樣可讓各種後端在實際可以正常使用之前，先處理系統呼叫宣告支援。

  • 系統呼叫介面將謹慎更新，在適當情況下符合新的 FIDL 建模方式。每次這類變更都將根據 RFC 而繼續進行。

  • 系統會產生 syscall C 標頭。

  • fidldoc 將會擴充，以從 FIDL 程式庫 zx 產生 syscall 說明文件。

  • 語言後端會擴充以產生系統呼叫繫結，程式碼會遷移為使用繫結繫結。

  • FIDL 程式庫 zx 將在 SDK 中匯出。

  • 這些獨立程式庫將以 FIDL 的方式提供 syscall 包裝函式和資料類型，將會淘汰。

效能

這個提案不會對效能造成任何影響。它巧妙地將各種語言現有系統呼叫發出邏輯的效能考量，轉移到相關聯的 FIDL 語言後端。雖然實際上在實務上，由於系統呼叫資料類型的表示法和我們維護的語言繫結之間必須一致，因為 Rust 繫結已採用 fuchsia-zircon 類型 Crate，以及搭配 C++ libzx 的 LLCPP 繫結，僅為系統呼叫程式碼繫結的元件進行修改。

具體而言，我們會按照後續 RFC 針對這個努力提出具體變更；如有，也會在這些論壇討論相關效能考量。

人體工學

改善項目：

  • 完整記錄的單一可靠資料來源。
  • 更簡潔且更容易的自攜裝置路徑。
  • 更簡便的系統呼叫演進與維護
  • 自動強制執行系統呼叫政策。
  • 與 syscall 相關的現有後端較容易維護 (例如 zxdb 和 fidlcat)，且有價值的新後端主機就不再易於寫入 (例如用於產生模糊引擎的系統呼叫說明，例如Syzkaller)，或產生系統呼叫 MSan (Memory sanitizer) 檢查的程式碼。
  • 語言繫結與 syscall 包裝函式之間沒有整合問題。

迴歸：

  • 系統會將 Syscall 繫結視為一般 FIDL 產生的來源，因此相較於今日對等的程式庫，這些繫結可能會變得較不易閱讀且更模糊。不過，缺乏有關產生來源或其可讀性的說明文件，並非系統呼叫特有的問題，因此即使不做這方面的努力，我們一般應盡力解決這項問題。
  • 對現有語言繫結有更多責任，程式碼表面更大，避免發生問題。

回溯相容性

針對這項工作，我們會按照後續 RFC 提出具體變更；如有相關的回溯相容性注意事項，我們會在這些論壇中討論。

安全性考量

如前所述，本提案將為更易於維護的系統呼叫支援，在我們的清理及模糊基礎架構中使用。

具體而言，我們會按照後續 RFC 提出具體的調整建議；如有，我們也會在論壇中討論相關的安全性考量。

隱私權注意事項

針對這項工作，我們會按照後續 RFC 提出具體變更；如有相關隱私權注意事項，我們會在這些論壇中討論。

測試

或者，在執行這個過程中，大部分都會導入到現有的子系統與測試制度：

  • 新的 FIDL 功能 (如現有功能) 將由 fidlc 和每個相關的後端的一般黃金測試組合來測試
  • 特定語言的 Syscall 繫結會取代我們目前手動維護的對等 syscall 包裝函式程式庫，因此任何經判定適合該語言的測試，都能更新為使用前者。具體來說，我們可以更新 Zircon 的核心測試，以便使用 C++ syscall 繫結，而我們在 //src/lib/zircon/rust Crate 中的單元測試也可以更新為使用 Rust syscall 繫結。
  • 此外，在這項工作中修改或重寫的任何其他後端 (例如 fidldoc) 或重寫，都會將現有的測試制度擴充或移植。

說明文件

新的 FIDL 功能記錄的方式與現有功能相同，並擴充了該語言的官方規格。此外，語言繫結的期望也會更新，以納入系統呼叫繫結的佈建作業。

缺點、替代方案和未知

這個狀態則承受著負擔：DL 系統對於維護 syscall 的維護工作相當繁雜 (DL 需另外考量，無須顧及其他公用介面維護所需之防護機制；任何軟體若將 syscall 介面做為其輸入內容，但其基礎，不構成 Fuchsia 本身就能達成這個狀態；就本身而言，這個平台代表其核心功能不完善，但 Fichsia 會認為這個平台具有核心功能，甚至會承受其基礎的功能，因為其本身俱有核心功能，但其核心類型資訊，zx_*

其中有許多不適當的原因，而且大部分的內容都已經固定地發展，這代表要解決的事項需要花費許多心力。必須瞭解這個提案的目標 是長而易懂的道路FIDL 和核心/vDSO 維護人員必須進行大規模的持續投資，而這些投資有時可能會幹擾每個人。如果不保持合理的配速，可能會產生按比例計費的轉場狀態。若是要求變更 Syscall 介面，則可能會在後續作業中收到一些小問題。

最終狀態的費用應受限於官方 FIDL 工具提供進行中的系統呼叫支援，這些費用應該相對有限且缺乏接觸。可能認為 fidlc 的支援極為突兀，因為我們最終需要「一些內容」才能充分瞭解並強制執行完整的系統呼叫語意 (甚至進而對該前端的備援功能產生價值)。此外，在語言後端產生 syscall 繫結的邏輯，應從 IR 編碼的簽名到來源宣告的簡單機器翻譯結果、採用線編碼的應用方式，並執行已維護的 FFI 層呼叫至 vDSO。

替代選項：

  • 不執行任何動作。
    • 我們目前處於難以理解的狀態，所以會推動這項遠大的提案。只要採取行動，就會繼續目前的維護負擔，因為新開發人員在嘗試移植現有軟體和執行階段時，會更加費力，目標對像也越來越能累積。
  • 我們投資新的印尼盾。
    • 我們甚至可以與 FIDL 結合交互作業，只希望針對機器可理解的靜態介面說明，同時協助我們為平台帶來大量的價值。
    • 不過，「Banjo」的歷史其實很實用，而且可能不是平台不想重複的記錄。
  • 之前為了建立模型，而嘗試變更系統呼叫介面。
    • 雖然可以這麼做，但這麼做將形成諸如上述設計目標和原則，並縮減旨在解決這些問題。

先前的圖片和參考資料

  • GNU Mach Mikernel 採用相同的 IDL 來定義其系統呼叫和處理序間通訊 (請參閱這裡的 .def 檔案，以及這裡瞭解編譯器 (MIG))。目前 Darwin 中仍會用到這個系統。

  • //zircon/vdso v1 表示法代表平台在進行 FIDL 評估的 syscall 時，首次嘗試。

  • Banjo 並非 FIDL 平台 IDL。