| 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 團隊會議中多次討論 FIDL 2023 的計畫。
設計
這項提案的目標是定義 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。與較新的對等端通訊時，程式無法解碼訊息。這不違反 FIDL 2023。
負面示例：我們會變更線格格式，以便為資料表使用稀疏表示法。程式無法使用此表示法解碼訊息。即使我們使用標記進行軟性轉換，這項做法仍違反 FIDL 2023，因為仍需要重新編譯程式。
正面範例：我們在 FIDL 中新增了
uint128類型。程式無法解碼此類型。這不違反 FIDL 2023，因為uint128並非 FIDL 2023 的一部分。如果程式使用的通訊協定不使用uint128，就沒有問題。如果這些值以與 ABI 相容的方式演進，在程式編譯後使用uint128，也不會有問題，因為這類值必定會位於信封或新方法中。最後，如果變更為使用uint128發生在編譯程式之前，則程式可安全地解碼uint128值。
正面範例：我們會變更互動模式，允許由伺服器啟動的雙向方法。這項操作不會違反 FIDL 2023，原因與上述
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 更難演進和改善。舉例來說，變更線路格式會耗費更多成本。我們不僅必須使用標記執行軟性轉換 (如同先前所述)，還必須保留舊的讀取路徑更久的時間，即使我們認為沒有任何東西會依賴該路徑也一樣。
替代方案：其他時間長度
這項提案顯示我們更重視長期相容性。三年的時間大致上是合理的。這比我們先前提供的相容性更長。但這只是其中一個原因。我們可以承諾不同的年限。
不明：實際上 ABI 相容性
我們仍在瞭解 Fuchsia 的長期 ABI 相容性實際情況。理想情況下，FIDL 可提供穩定的基礎，讓開發人員用於改進應用程式和服務。我們過去曾對 FIDL 進行重大變更，以便更好地支援可進化性和相容性，例如 RFC-0061：可擴充的聯集。FIDL 2023 是否具備上述層級所需的所有功能，以提供長期相容性，還是缺少某些功能？
既有技術與參考資料
所有成功的作業系統都會提供一定程度的長期相容性。毫無疑問，Fuchsia 和 FIDL 也需要這麼做。
長期支援版本的概念在開放原始碼軟體中很常見。舉例來說，Linux 核心將特定版本指定為「長期」版本。