| RFC-0229：FIDL 2023 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 目前的 FIDL 傳輸格式與互動模式 (稱為 FIDL 2023)，將支援至少三年。 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 |
|
| 提交日期 (年/月) | 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
社交化：FIDL 2023 的計畫在撰寫此 RFC 之前曾多次討論 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程式在與較新的對等點通訊時，無法解碼訊息。此內容未違反 FIDL 2023。
負例：變更線路格式，以便為資料表使用稀疏表示法。程式無法使用此表示法將訊息解碼。此情況違反 FIDL 2023，即使我們使用旗標進行柔性轉換變更，仍需要重新編譯程式。
正面示例。我們在 FIDL 中新增類型為
uint128。程式無法解碼這種類型。這未違反 FIDL 2023，因為uint128並非 2023 FIDL 的一部分。如果程式使用的通訊協定未使用uint128，表示沒有問題。如果在程式編譯「之後」，利用與 ABI 相容的方式發展成使用uint128，也沒有問題，因為這些值必須一直位於信封或新方法中。最後，如果使用uint128的變更是在編譯程式「之前」發生，程式就可以安全地解碼uint128值。
正面示例。我們更改互動模型，允許伺服器啟動的雙向方法。這未違反 2023 年 FIDL 2023 規定，原因與上述
uint128範例類似。
負例：我們改變互動模型，以允許用戶端將 API 傳送至伺服器。這個程式可能會實作伺服器，無法正確處理這類訊息，因此違反 FIDL 2023。
這些範例顯示傳輸格式和互動模型仍可變更，但變更必須具有累加性和啟用性 (例如選擇在新 API 中使用 uint128 類型)。在 FIDL 2023 支援期間，未選擇啟用新功能的程式碼必須能繼續使用。
效能
我們承諾長期支援 FIDL 2023，意味著我們無法透過變更傳輸格式來改善現有功能的效能。
人體工學
這項提案不會影響人體工學。
回溯相容性
本提案的重點在於回溯相容性，因此會全程討論，而非本節內容。
安全性考量
如果我們發現安全性問題需要進行不相容的變更，可能就會破壞 2023 年全面支援 FIDL 2023 的承諾。
隱私權注意事項
如果我們發現隱私權問題需要進行不相容的變更，我們可能會破壞 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 kernel 將某些版本指定為「長期」。