定義穩定驅動程式執行階段

  • 專案主管：surajmalhotra@google.com
  • 狀態：已核准
  • 區域：裝置

問題陳述

Banjo 是一種介面定義語言 (IDL)，用來表示驅動程式之間使用的介面。它是 FIDL 的導數，其語法為 2018 年。雖然語法類似，但與 FIDL 不同，Bbanjo 則是用於同步處理中的通訊，並將產生的程式碼產生金額轉換成非常輕微的函式指標結構，該結構與結構定義指標相關聯。

以下列舉一些關於 banjo 的問題：

  • 針對 banjo 產生的程式碼缺少介面和類型演進策略。這是介面穩定性的重要條件。
  • 自 2019 年初起，Banjo 主要處於維護模式，並在人體工學和功能方面下落於 FIDL 後方。由於 Fuchsia 專案仰賴 FIDL 說明文件來解決班鳩琴功能和人體工學方面的缺口，因此瞭解如何編寫斑鳩琴語法會讓人感到困惑。
  • Banjo 經過最佳化以享有低負擔，為駕駛人提供大量負擔，以便瞭解如何將狀態移至堆積或以非同步的方式處理作業。有許多需要使用手動序列化邏輯的樣板。
  • 針對駕駛人如何叫用斑鳩琴通訊協定方法，也沒有保證可在哪個情境叫用自身的通訊協定方法，導致為了確保安全 (避免死結) 而產生不必要的執行緒。
  • Banjo 類型與 FIDL 類型不相容，在改用程序外的通訊時，通常會導致樣板產生許多樣板。

解決方案陳述

我們致力於改進斑鳩琴以解決此問題。這三項新傳輸的三個主要特色如下：

  1. 驅動程式之間的強制間接層，讓執行階段能在相同程序中，推動驅動程式庫人之間的通訊
  2. 從 C 結構的逐步遷移改為考慮演進建構的類型。
  3. 針對定義明確的執行緒模型強制執行

我們期望能找到具有以下特性的解決方案：

  • 將驅動程式之間的所有通訊改為訊息導向，並在驅動程式之間使用 FIDL 傳輸格式。
  • 允許駕駛人同步呼叫其他驅動程式。
    • 請注意，您只能在驅動程式庫擁有的執行緒上使用這項功能。
  • 在驅動程式之間共用執行緒
    • 注意：共用執行緒的所有通訊都必須非同步。
  • 在未選擇使用的情況下，允許駕駛人一律不處理重新進入或同步處理作業 (讓他們完全避免鎖定)。
  • 允許驅動程式之間零複製或零序列化 / 去序列化。

我們保留根據早期原型的基準結果改變想法的權利。如果我們無法優於核心提供的機制，就會需要嘗試其他設計。我們也必須證明自己假設核心提供的機制不足以滿足我們的需求。

我們將嘗試根據下列里程碑追蹤新斑鳩琴進度：

  1. 更新 banjo 語法以符合 fidl 語法、使用 fidlc 做為前端，並實作自訂後端，以產生與目前 banjoc 相等的輸出內容。
    1. 這種設定可避免發生維護負擔，並避免日後的語法偏移。
  2. 為想要設計的驅動程式建構執行緒模型。
  3. 決定指標/基準，判斷任何即將推出的設計。
  4. 請執行實驗，確認我們能否透過較新的傳輸方式達成必要的基準測試。
  5. 實作新的 Fidl 後端和驅動程式庫執行階段。
    1. 我們可能會先建立用來指定新傳輸的 LLCPP fidl 繫結變化版本。
  6. 針對迴圈中的每個驅動程式庫堆疊重複下列步驟：
    1. 利用現有的斑鳩琴傳輸，將同一驅動程式代管程序中共同使用的驅動程式遷移至新的執行緒模型。
    2. 將同一驅動程式代管程序中共同使用的驅動程式遷移至新的處理中 FIDL 傳輸。

依附元件

我們可能必須與 FIDL 團隊合作，允許來自 zircon 管道和通訊埠的 LLCPP 繫結，讓我們能在新傳輸中依原樣重新利用繫結，盡可能減少使用者明顯的差異。我們預期不會對前端 IDL 做出任何必要變更，但可能需要變更 FIDL IR。

此外，遷移超過 300 個驅動程式不僅耗費大量心力和時間，而且需要在整個機構中各團隊參與，確保沒有任何中斷情形。

風險與緩解措施

這類重大變更會帶來額外的負擔，長期影響系統的效能特性。幸好，我們在架構的架構中內建一些重大的支援功能，能夠在我們建構的解決方案無法滿足未來需求時，改採其他技術。具體做法是實作新的元件執行器，並讓驅動程式以新的執行元件做為目標，這些執行器可能會有不同的驅動程式庫執行階段。不過，將每個驅動程式庫切換至新的驅動程式可能並不實際，但最終還是需要同時維護兩個驅動程式，但費用會增加。因此，我們最希望採取上述做法以最妥善的方式完成，這樣就不必上課。

將驅動程式切換至新的執行緒模型也會帶來很高的費用，而且一路過程中可能會產生新的錯誤。許多駕駛人都沒有測試。此外，對於已有測試的驅動程式，單元測試可能也會在切換後失去有效性，且可能需要隨轉換而重新編寫。我們編寫了大量驅動程式庫測試做為整合測試，即使遷移後未有任何變更，這些測試依然有效。我們會持續嘗試投入更多整合測試和 e2e 測試，再進行遷移，以免產生新錯誤。

預估遷移作業的遷移時程也是另一項高風險。如果沒有在至少一個驅動程式庫上建構替代與試用遷移，就很難準確預估費用。我們在設計設計的過程中，必須持續辨識成本，並盡可能自動執行遷移作業。