| RFC-0229：FIDL 2023 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 目前的 FIDL 線路格式和互動模型 (稱為 FIDL 2023) 將至少支援三年。 |
| 問題 | |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2023-08-29 |
| 審查日期 (年-月-日) | 2023-10-11 |
摘要
這份文件指出，目前 FIDL 線路格式和互動模型 (稱為 FIDL 2023) 將至少支援三年。
提振精神
FIDL 包含許多內容：語言、編譯器、繫結、線路格式和互動模型。本 RFC 著重於後兩者，因為這兩者與 ABI 相容性有關。這兩者多年來都有顯著變化。舉例來說，我們最近遷移了 RFC-0113：有效信封的線路格式，並修訂了 RFC-0138：處理不明互動的互動模式。我們瞭解所有使用 FIDL 的程式碼，因此可以更新所有程式碼，進而完成這些變更。未來隨著平台日趨成熟，這種情況將不復存在。我們需要開始思考長期 ABI 相容性。
利害關係人
協助人員：abarth@google.com
審查人員：hjfreyer@google.com、ianloic@google.com、sethladd@google.com、ddorwin@google.com
諮詢對象：quiche@google.com、wilkinsonclay@google.com
社會化：在撰寫這份 RFC 之前，FIDL 團隊會議已多次討論 2023 年 FIDL 計畫。
設計
這項提案的目標是定義 FIDL 2023，並批准相關計畫，確保自接受本 RFC 起至少三年內支援該語言。
範圍
FIDL 2023 是指截至 2023 年 9 月的 FIDL 線路格式和互動模型狀態。FIDL 的其他部分不在涵蓋範圍內。
線路格式會指定 FIDL 訊息在線路上的編碼和解碼方式。 包括互動模式中使用的交易訊息，以及透過 RFC-0120 API 進行獨立編碼和解碼的其他用途。線路格式已記錄，但有幾點值得注意：
- 這個神奇數字是 1。對於任何其他魔術數字，解碼都必須失敗。
- 靜態旗標包括「v2 指標」
0x0002。如果未設定這個位元，解碼作業就必須失敗。 - 其他旗標位元不得經過驗證。解碼時不得因目前未使用的靜態旗標或動態旗標值而失敗。
互動模型會指定 FIDL 用戶端和伺服器必須採取的行為。舉例來說，如果 FIDL 對等互連端點無法解碼傳入的訊息，就必須關閉管道端點。互動模型尚未提供完整說明文件 (請參閱說明文件)，但已在 FIDL dynsuite 中經過測試。
FIDL 2023 包含所有 RFC 的連線格式和互動模型變更，特別是下列項目：
請注意，並非所有繫結都已實作部分 RFC。特別是 Go 和 Dart 繫結尚未針對 RFC-0137 更新。因此不完全符合 FIDL 2023 規範。
支援
FIDL 2023 是 FIDL 線路格式和互動模型的長期支援 (LTS) 版本。自接受本 RFC 的日期起，至少會支援三年。
這並不妨礙在 FIDL 中新增功能。您只需要維持與 FIDL 2023 的相容性即可。此外，如果我們新增任何功能，這些功能不會自動納入 LTS 保證。
具體來說，假設有人編譯使用 FIDL 2023 的程式，在支援期間，該二進位檔應可正常運作 (「正常運作」的程度取決於 FIDL)，前提是：
- 軟體堆疊的其餘部分 (特別是 Zircon 和元件架構) 維持類似的長期相容性。
- 使用的 FIDL 通訊協定維持不變，或以 ABI 相容的方式演進；
- 與其通訊的對等互連節點維持應用程式層級的相容性。
以下列舉一些正面示例 (提案允許) 和負面示例 (提案不允許)，說明 FIDL 2023 支援的意義。
正向範例。程式會使用含有結構體的通訊協定。我們在這個結構體中新增欄位，導致 ABI 中斷。與較新的對等互連裝置通訊時，程式無法解碼訊息。這並未違反 2023 年 FIDL。
負例。我們將線路格式變更為使用資料表的稀疏表示法。程式無法使用這個表示法解碼訊息。 即使我們使用標記以軟性方式轉換變更，這仍違反 FIDL 2023，因為這仍需要重新編譯程式。
正向範例。我們在 FIDL 中新增了
uint128型別。程式無法解碼這類檔案。這不違反 FIDL 2023，因為uint128不屬於 FIDL 2023。如果程式使用的通訊協定未採用uint128，就不會有問題。如果這些值以 ABI 相容的方式演進，在程式編譯後使用uint128after，也不會有問題，因為這些值必然會位於封包或新方法中。最後，如果使用uint128的變更在編譯程式前發生，程式就能安全地解碼uint128值。
正向範例。我們變更了互動模式，允許伺服器啟動雙向方法。這不會違反 2023 年 FIDL，原因與上述
uint128範例類似。
負例。我們變更互動模型，允許用戶端將墓誌銘傳送至伺服器。這違反了 FIDL 2023，因為程式可能會實作伺服器，且無法正確處理這類訊息。
這些範例顯示，連線格式和互動模式仍可能變更，但變更必須是加法且可選擇加入 (例如選擇在新版 API 中使用 uint128 型別)。未選擇使用新功能的程式碼，在 FIDL 2023 支援期間，必須繼續運作。
效能
我們承諾長期支援 FIDL 2023，因此無法透過變更連線格式來提升現有功能效能。
人體工學
這項提案不會影響人體工學。
回溯相容性
本提案主要在於回溯相容性，因此會在全文中討論，而非僅限於本節。
安全性考量
如果發現安全問題，我們可能需要進行不相容的變更，因此無法完全支援 FIDL 2023。
隱私權注意事項
如果發現隱私權問題，需要進行不相容的變更，我們可能會無法完全支援 FIDL 2023。
測試
我們會繼續使用 GIDL 測試線路格式，並使用 dynsuite 測試互動模型。我們也會投入資源擴大這些測試，以涵蓋更多 FIDL 2023 功能和極端情況。這有助於確保我們能履行長期支援的承諾。
說明文件
我們必須更新 FIDL 傳輸格式規格。舉例來說，除非另有註明，否則所有內容皆為 FIDL 2023 的一部分。
FIDL 繫結規格記錄了互動模型的某些層面，但其中也混雜了有關所產生繫結結構和樣式的指南。我們必須改為建立新的「FIDL 互動模型規格」。其中的每個陳述式都應以 dynsuite 測試為依據。
缺點、替代方案和未知事項
缺點：較難改善 FIDL
這項提案會讓 FIDL 的演進和改良更加困難。舉例來說，變更線路格式的成本會高出許多。我們不僅必須使用旗標執行軟轉換 (如先前所述)，還必須保留舊的讀取路徑更長的時間，即使我們認為沒有任何項目依賴該路徑也是如此。
替代方案：其他時間長度
這項提案表示我們更加重視長期相容性。 三年大致上是適當的期限。這比我們以往提供的相容性支援時間更長。但除此之外，這項技術就沒有其他用途了。我們可以承諾不同年數。
Unknown：實務上的 ABI 相容性
我們仍在瞭解 Fuchsia 的長期 ABI 相容性在實務上會是什麼樣子。理想情況下，FIDL 會提供穩定的基礎，供開發人員用來演進應用程式和服務。過去，我們曾對 FIDL 進行重大變更，以利支援可演進性和相容性，例如 RFC-0061：可擴充的聯集。FIDL 2023 是否具備上層提供長期相容性所需的所有功能，還是缺少某些功能？
既有技術和參考資料
所有成功的作業系統都會提供一定程度的長期相容性。 毫無疑問，Fuchsia (因此 FIDL) 也需要這麼做。
長期支援版本是開放原始碼軟體中常見的概念。 舉例來說，Linux 核心會將特定版本指定為「長期」版本。