| RFC-0241：明確平台 / SDK 介面中的外部分割 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 更精確地表示 Fuchsia 介面外，可在 Fuchsia 平台外實作的哪些部分。 |
| 問題 | |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-01-29 |
| 審查日期 (年-月-日) | 2024-04-09 |
摘要
Fuchsia IDK 未指明是否應實作外部元件 用戶端或伺服器。如此一來 難以正確評估 Fuchsia API 的異動。這個 RFC 提議以 適用於人類和機器可讀取的 FIDL 方法這將開創 改善 Fuchsia 產品的正確性和穩定性。
提振精神
許多 Fuchsia 系統介面是以 FIDL 是一組通訊協定，以及 會透過那些通訊協定交換通訊協定與用戶端之間不對稱 和伺服器端的 FIDL 宣告 SDK/IDK 未指定 Fuchsia Platform 提供的介面 產品提供的外部元件適用於伺服器端 將容器分成兩邊或兩側
缺乏精確性會嚴重限制了 安全地進入 Fuchsia 系統介面 實作 Fuchsia 平台，且通常是外部元件。於 大部分通訊協定都只有伺服器或只有用戶端。 導入 Fuchsia 平台導入，但本資訊並未 並開放開發人員透過工具檢查或找到
舉例來說，如果系統介面一部分的類型包含
string:100 (以 UTF-8 編碼時，最多佔用 100 個位元組的字串) 和
後來意識到，我們需要支援較長的字串。如果只在這個類型中
是否曾從外部元件傳送至平台元件 (在通訊協定方法中)
要求)，然後可以放心提高長度限制，因為
解碼元件中至少含有該字串的訊息
視為元件編碼的新物件如果該類型可能從平台傳送
就無法安全地增加
因為根據平台中較新的 API 級別建構的元件
不小心將格式錯誤的訊息傳送至外部元件
相關人員
誰會負責確認 RFC 是否已獲接受？
講師：
FEC 任命的人員，透過 RFC 處理此 RFC 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作
審查者：
- abarth@google.com
- chaselatta@google.com
- hjfreyer@google.com
諮詢：
- aaronwood@google.com
- awolter@google.com
- crjohns@google.com
- mkember@google.com
- pesk@google.com
- surajmalhotra@google.com
- wittrock@google.com
社交功能：
編製單頁簡介，向工作人員說明問題和提案 。
需求條件
下列關鍵字：「必須」、「不得」、「必要」、「應」、「不應」、「應該」、「應該」、 「不應該」、「建議」、「可能」和「選用」基本上就是 解讀方式 IETF RFC 2119。
我們必須能夠明確表達出哪些系統介面通訊協定 或在平台或外部元件中實作。這個 資訊的呈現方式必須要讓工具能夠存取 平台的相容性變動。
這項資訊「應」提供給在軟體組譯期間執行的工具 而且可在執行階段中供元件架構使用這項資訊 應該透過產生的 API 說明文件和 建構時間檢查
為了讓這些資訊有助於評估 Fuchsia 平台和其基礎元件「必須」建立外部元件 與平台支援的穩定 API 級別比較
設計
分析
平台 ABI 介面的整體相容性可細分為 考量到外部交換器的個別類型 分別在管道和平台的通訊協定中 序列化後從錶帶上取下。
元件之間所有 FIDL 資料交換作業都是採用下列其中一個根層級：
- 透過元件交換的 FIDL 通訊協定
架構通訊協定功能。這類標籤會標示為
@discoverable屬性。 - 透過非 FIDL 方式交換的 FIDL 通訊協定，例如處理程序 引數,
- 已序列化並在檔案中交換的 FIDL 類型 (例如 元件資訊清單) 或自訂處理序間通訊 (IPC) 傳輸。
考慮到整個 Fuchsia 系統介面 FIDL 的檢視，每個根 收集用戶端和伺服器之間傳送的資訊類型 伺服器對用戶端
通訊協定
如果想要瞭解每個「根」通訊協定和伺服器 導入外部元件或平台元件中，我們就能收集 可從外部元件傳送至平台元件的一組類型 從平台元件到外部元件 和外部元件之間的連線
針對通訊協定：
@discoverable
protocol {
M(Req) -> (Resp);
}
我們可以看到用戶端和伺服器可以導入的位置 要求中的類型 (要求) 和回應 (回應) 可能會在外部 元件 (E) 和平台元件 (P)：
| 用戶端 | 伺服器 | E 到 P | P 到 E | P 到 P | E 到 E |
|---|---|---|---|---|---|
| E | E | 請求與回應 | |||
| E | P | 要求 | 回應 | ||
| E | P、E | 要求 | 回應 | 請求與回應 | |
| P | E | 回應 | 要求 | ||
| P | P、E | 回應 | 要求 | 請求與回應 | |
| P、E | E | 回應 | 要求 | 請求與回應 | |
| P、E | P | 要求 | 回應 | 請求與回應 | |
| P、E | P、E | 請求與回應 | 請求與回應 | 請求與回應 | 請求與回應 |
平台程式碼保證可讀出所說通訊協定版本的超集 進而瞭解類型限制是否能 放鬆或放鬆：
| 寄件者 | 接收器 | 限制 |
|---|---|---|
| 外部 | 平台 | 無法鎖緊 |
| 平台 | 外部 | 沒辦法放鬆 |
| 外部 | 外部 | 無法變更 |
因此，我們必須要能限制用戶端和伺服器
「幾乎」所有根通訊協定會透過元件架構交換
即便沒有技術背景，也能因這些工具的功能而受益不屬於低階和玄秘主題的信號。包括
fuchsia.io.Directory 和幾個網路通訊端控制管道通訊協定
fuchsia.posix.socket。與其開發新的標示通訊協定
做為通訊根，我們應擴充 @discoverable 的意義
納入這些通訊協定。事實上
fuchsia.posix.socket 代表即將發布的通訊端控制通訊協定名稱
標記為 @discoverable 後自動產生。
類型
目前任何元件 (外部或平台) 程式碼都可以序列化或還原序列化 原始位元組中的任何非資源類型。為了讓相容性工具知道 在某些情況下，FIDL 類型「不會」序列化或反序列化 明確標記在一般 FIDL 之外元件之間傳遞的類型 處理序間通訊 (IPC)
語法
通訊協定
「可搜尋」屬性將擴充以明確顯示位置
通訊協定預設會標示 @discoverable 的通訊協定
可能擁有由外部元件和外部元件
平台元件
server 和 client 選用屬性會列出
可能會實作該類型的端點根據預設，兩個端點皆可
任何元件實作的使用者介面
例如：
// All servers in the platform, all clients in external components.
@discoverable(client="external", server="platform")
protocol P {};
// All servers in external components, all clients in the platform.
@discoverable(client="platform", server="external")
protocol Q {};
// Only clients allowed in external components, both clients and servers allowed in the platform.
@discoverable(client="platform,external", server="platform")
protocol R {};
// Servers are only allowed in platform components. Clients are allowed anywhere.
// If both clients and servers are allowed that argument can (and should) be omitted.
@discoverable(server="platform")
protocol S {};
類型
系統會將新的 @serializable 屬性新增至 FIDL，以標明可能
在 FIDL 通訊協定之外的元件之間傳遞序列化和傳送的訊息。
這項屬性只適用於非 resource struct、table 和
union。
它有兩個選用引數：read 和 write。每個項目都會採用半形逗號
platform 和 external 的清單，指出平台是否
元件或外部元件應讀取或寫入該類型。
每個引數的預設值是 "platform,external"，表示可以
讀取及寫入該元件
實作
FIDL 工具鍊
fidlc 將會更新，以接受 @discoverable 和
新屬性 @serializable。FIDL 繫結產生器 (fidlgen_*) 不會
尚未修改。
Fuchsia 系統介面
partner 和 partner_internal 程式庫中所有可探索的 FIDL 通訊協定
「 」即將更新。大多數都會標示為@discoverable(server="platform")
表示外部元件應該只實作用戶端，而平台必須
可能會實作用戶端和伺服器部分，例如 fuchsia.io 中的多個
將標示為 @discoverable()，表示任何元件皆可實作
用戶端和伺服器少數幾個會標示司機，
@discoverable(client="platform", server="external")：表示外部
只應實作伺服器和平台元件
以及實作用戶端
經過一些實驗和原型設計後 以便直接計算各個通訊協定所屬的類別。 未檢查元件圖表的執行階段，也不會對 CML 進行靜態評估 資料分割很清楚。我們會改為查看外部元件的資訊清單 瞭解所使用的通訊協定功能
針對獨立資料類型，我們會尋找各種語言 繫結明確的序列化 API，並加上註解 才是正確的做法
相容性工具
我們正在開發工具，可以評估不同版本網頁的相容性 Fuchsia 系統介面的 FIDL IPC 部分。這項做法與 FIDL IR，並納入可偵測屬性的資訊。A 罩杯 這項工具將執行相容性規則的完整說明 也會出現在另一個 RFC
未來機會
我們之所以優先推出 FIDL 的強化功能，主要原因在於相容性工具 語法。不過，這些 Fuchsia 系統介面的更豐富的資訊 在其他地方也發揮實用價值
FIDL 繫結
FIDL 繫結產生器可瞭解其是否在建置 同時指定平台元件或外部元件的繫結 開發人員產生的程式碼，鼓勵開發人員只實作用戶端和伺服器 採用相容通訊協定的通訊協定。
要防止任何不受支援的用戶端或伺服器會產生反效果，因為 開發人員必須能夠在測試中假造或模擬其他開發人員 可施加護衛，以勸阻他們在非測試情境中使用。
獨立序列化程式碼可更新，以便只接受
並標示為 @serializable，以便傳入。
元件架構
在元件架構中，通訊協定功能為無類型。這通常 命名，但這只是一種慣例 違反政策。解釋特定元件通訊協定的工具 和同事溝通時必須憑空猜測 能夠瞭解要使用哪些通訊協定
如果元件架構在模型中加入通訊協定類型，這些工具就會 更加簡單、更可靠且正確。
軟體組件
軟體組件會利用配置和平台產生 Fuchsia 系統映像檔 以及外部元件並使用 通訊協定可能來自平台元件或外部以拒絕 構成違反這些規則的產品這樣產品就能確保 老闆不會不小心建構能夠保證相容性的產品 並協助平台開發人員避免 導入意外解鎖機制
安全性
瞭解哪些通訊協定功能的結尾是經過外部 / 轉送 平台界線可用於評估 有些人會將 Cloud Storage 視為檔案系統 但實際上不是這項作業可以臨時完成，或整合至現有 工具
成效
成效將維持不變。
人體工學
這需要系統中的部分假設必須明確表達。 需要多點工夫，但可讓系統更容易 希望您能輕鬆理解並運用
回溯相容性
現有的 FIDL 程式庫不會受到影響。@discoverable (不含引數)
仍是有效屬性
一開始，我們不會要求建立可對物件進行可序列化的版本 屬性是版本管理的輸入內容，因此不會影響來源或 必須廣泛採用才能享有好處如果我們 更新 FIDL 繫結，根據偵測到的問題變更 就必須考慮版本管理，因為變更這些引數可能會破壞 生成的內容
安全性考量
這個區域未來可能有商機，為提升整體成效 以及系統安全性
隱私權注意事項
無
測試
如此便能輕鬆確保我們達成完全的相容性 對 Fuchsia 平台的明確編碼， 與保證相容性的通訊協定相同。
我們會針對所有 fidlc 變更新增 fidlc 測試。
直到我們於組裝時驗證所有元件均遵循 因此我們無法確定已確認外部 / 的 我們透過 SDK 呈現的平台分割畫面，符合 Fuchsia 的實際情況 很少直接解答該如何打造產品
說明文件
部分 FIDL 說明文件需要更新：
缺點、替代方案和未知
我們可以維持現狀，但這樣會大幅限制 我們可支援的幾種改變，或限制工具的可信度 以檢查變更是否安全
我們能以 FIDL 語言以外的方式表示外部 / 平台分割為 與 API 工具一樣 (就像針對 SDK 類別的情況一樣)，但由於這是 發生在非人體工學的宣告層級 直到過時
相對於使用 @discoverable 標記 fuchsia.io.Directory 等通訊協定，
我們就可以想出對等的屬性
相容性，但不支援通訊協定功能。感覺
化繁為簡
與其新增 @serializable 來標示從錶帶外交換的類型，
我們可以直接寫入使用這些輸入的預留位置 FIDL protocol
標記了 @discoverable 並加上適當屬性，以表示這些型別的位置
讀取及寫入這意味著，有些通訊協定
而且通常難以理解正確而混亂。
我們不使用 @discoverable(server="platform", client="external") 這類語法
使用「@discoverable(platform="server", external="client")」一小段時間
但目前的語法比較容易理解
既有藝術品和參考資料
不適用