| RFC-0213：移除 devfs FIDL 多工處理 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 概略說明在 devfs 中移除 FIDL 多工處理的理由和計畫 |
| 問題 | |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 2023-03-28 |
| 審查日期 (年/月) | 2023-03-17 |
摘要
本提案概述移除 devfs 功能的程序，其中的多個 FIDL 通訊協定會透過單一連線進行多工處理。說明移除這項功能的原因為何會解除封鎖新的驅動程式庫功能，並將與 Fuchsia 中的其他驅動程式庫 FIDL 連線標準化。
提振精神
驅動程式架構會管理硬體裝置和用戶端之間的連線。過去，這項連線提供了三種 FIDL 通訊協定：
fuchsia.io/Nodefuchsia.device/Controller- 裝置實際的 FIDL 通訊協定
這種多工處理需要驅動程式架構擁有管道，才能提供節點和控制器通訊協定。這樣可以防止底層驅動程式庫擁有管道。這項設計意味著驅動程式架構必須在驅動程式與驅動程式主機之間維持 C FIDL 邊界。這也表示驅動程式無法區分多個連線或每個連線狀態之間的商店。這項限製造成許多「彈跳床通訊協定」，也就是驅動程式庫和用戶端交換新一對管道的通訊協定，藉此避免多工通道。
這項多工處理違反組合的 FIDL 設計原則。FIDL 設計原則指出在編譯期間，通訊協定可以是多個通訊協定的 composed。不過，驅動程式架構會在執行階段執行這個組合，並不知道裝置喚醒的 FIDL 通訊協定。在執行階段中，多工功能也會遇到在屬於多工處理的通訊協定中發生衝突的序數。
控制器通訊協定的多工處理代表無法使用能力轉送功能限制對 fuchsia.device/Controller 的存取權。舉例來說，/dev/class/input-report 的用戶端大多想要存取 fuchsia.input.report/Device。不過，fuchsia.device/Controller 會在同一個管道中提供，因此能夠解除繫結、重新繫結或設定這些裝置的電源狀態。如果裝置的 FIDL 和控制器 FIDL 在同一管道上進行多工處理，則無法解決這個轉送問題。
在程式碼集內，節點的多工處理會使用節點通訊協定的多工功能複製與裝置的連線。雖然複製裝置連線的概念相當簡單，但這是基礎驅動程式庫所不知道的能力。此外，fuchsia.io/Node.Clone 的 API 會包含 fuchsia.io/Node 的伺服器端，因此使用這個 API 複製裝置版本時，會影響管道的基礎類型。如今，有許多用戶端程式碼需要利用，例如直接呼叫 FIDL 或是使用檔案描述元。Fuchsia 使用輸入管道的既有最佳做法，因此應該在這個領域強制執行這些最佳做法。
相關人員
講師：
- Abarth
審查者：
- Abarth
- Cja
- Cuter
- 蘇拉吉馬霍特拉
- 塔米德
- 葉菲
顧問：
社群媒體化：
這份 RFC 最初是設計文件，內容與驅動程式架構團隊進行設計審查。
相關規定
需求條件分為兩類：「遷移」和「結束狀態」。
遷移
遷移計畫必須是透過許可清單進行軟性遷移。Fuchsia 包含許多與驅動程式庫用戶端互動的程式碼，包括樹狀結構內和樹狀結構外。您將無法一次移除所有 devfs 的多工處理。將獨立工作加入許可清單後，我們就能逐步執行進度，避免遷移作業恢復運作。
遷移作業應盡可能機械化。每個用戶端更新都應簡單明瞭，讓不熟悉驅動程式或驅動程式庫程式架構的使用者都能執行遷移作業。每次更新的機械化程度越高，遷移作業的速度就越快。
結束狀態
裝置連線不得明確。應明確指出用戶端是否會要求裝置控制器或基礎裝置通訊協定。不提供 FIDL 多工處理功能，因此用戶端能夠使用已輸入的管道。
驅動程式架構不會在與裝置連線中提供 fuchsia.io/Node。
駕駛人員可以擁有自己與客戶的連結。移除 FIDL 多工處理後，會再次遷移驅動程式，將驅動程式移至 DDK API；每當用戶端嘗試連線時，該 API 就會為驅動程式庫提供管道。這項遷移作業可讓驅動程式具有每個連線狀態，並使用其餘 Fuchsia 程式碼集使用的 FIDL 繫結。
設計
正在連線到 fuchsia.device/Controller
用戶端必須先在 devfs 檔案系統中開啟特定節點，才能連線至 fuchsia.device/Controller。這個節點將命名為 device_controller，且將可在 devfs 類別路徑和 devfs 拓撲路徑中使用。
如果用戶端從 /dev/class/input-report/abcd 取得裝置通訊協定，即可在 /dev/class/input-report/abcd/device_controller 取得控制器。
如果用戶端從 /dev/sys/platform/pci/00:12 取得裝置通訊協定，即可在 /dev/sys/platform/pci/00:12/device_controller 取得控制器。
從 /dev/class/ 移除多工處理
其中有兩個 devfs 類別路徑的許可清單，一個用於 fuchsia.io/Node，另一個用於 fuchsia.device/Controller。這些許可清單會包含 /dev/class/{protocol} 名稱，這些名稱仍對個別通訊協定進行多工處理。
更新用戶端以停止依賴多工處理行為後，系統就會移除這個許可清單中的項目。
從拓撲路徑中移除多工處理
針對類別路徑移除許可清單中的項目時，邏輯路徑中的對應項目也會從這些路徑中移除多工處理。
舉例來說，如果 /dev/class/input-report 已移除 fuchsia.io/Node，與這些輸入裝置相對應的地形路徑就不會再提供 fuchsia.io/Node。
實作
許可清單將於驅動程式庫架構中實作。從許可清單中移除項目時，您必須更新仰賴此多工處理的用戶端。
效能
移除 FIDL 多工處理應該不會對效能造成重大影響。由於傳送到裝置的 FIDL 訊息不需要嘗試分派給 Node 或 Controller API，因此效能可能會稍微提升。
人體工學
驅動程式架構可能會決定新增輔助程式庫，以便連線至 Controller API。具體情況取決於前幾項遷移作業。
如果用戶端嘗試在裝置上呼叫不明的 FIDL 通訊協定，驅動程式架構也會更新來記錄錯誤。這表示如果用戶端錯誤仍依賴多工處理，則會有 ERROR 記錄。遺憾的是，將錯誤記錄正確歸因至特定用戶端並不容易。
回溯相容性
您無法移除 FIDL 多工處理並保留回溯相容性。
安全性考量
這個提案沒有任何安全性考量。這項工作可能會使用戶端行為更明確且更瞭解，稍微提高 dev 的安全性。
日後，驅動程式架構會想限制 fuchsia.device/Controller 的存取權。舉例來說，可存取 /dev/class/input-report 的用戶端不需要存取控制器通訊協定。限制這項限制可提升安全性，移除 FIDL 多工功能會讓驅動程式架構日後能限制此行為。這個通訊協定的實際限制計畫不在 RFC 的涵蓋範圍內，因此可做為後續專案使用。
隱私權注意事項
本提案沒有任何隱私權注意事項。
測試
系統會測試許可清單的驅動程式架構功能和多工處理的移除作業。
每次移除許可清單時，都無法依賴 CQ 中現有的測試涵蓋範圍。由於這種多工處理作業是在 FIDL 類型系統之外進行，因此目前無法透過靜態方式判斷哪些用戶端依賴多工處理行為。
說明文件
已經以開啟專案頁面的形式新增說明文件 本頁面概述許可清單、動機和更新步驟。專案完成後，沒有任何用戶端取決於這個行為，因此不需要提供相關文件。
缺點、替代方案和未知
在 DFv2 中使用服務功能
目前進行這項工作的主要替代方案為，請等待驅動程式做為元件 (DFv2) 工作完成，然後再直接遷移用戶端至使用服務功能。
不過，在所有可能的主面板都啟用 DFv2 後，才能開始將用戶端遷移至服務功能。在此期間，將會新增更多仰賴多工處理的用戶端，包括較難遷移的樹狀結構用戶端。此外，DFv1 相容性填充必須支援 FIDL 多工處理功能，以保留現有行為，而自行匯出至 devfs 的 DFv2 驅動程式也必須支援多工處理。從 DFv1 移除這項技術債將簡化 DFv2 設計，而不需要向前保留這項技術債。
如果用戶端同時需要同時尋找 FIDL 多工處理，將用戶端遷移到服務功能的難度會提高。如果一次修正問題，這些遷移作業會更快執行。
先前的圖片和參考資料
FIDL 已列出通訊協定組合的最佳做法。