Fuchsia 平台可更新性

什麼是平台可更新性？

產品需求會隨時間改變，因此 Fuchsia 必須要做出變更才能符合這些條件。

新的平台版本可能會提供新功能和錯誤修正。與 Fuchsia 平台整合的產品擁有者可能只需要在新平台建構上重新建構現有產品組件。視產品的性質和更新方式而定，使用者可能甚至可以直接從 Fuchsia 專案收到平台的更新。視組合的產品性質而定，產品擁有者可能無法將現有應用程式軟體移植至新的平台版本，而必須依賴現有預先建構的應用程式，才能持續對新平台預先建構的運作。

Fuchsia 的設計宗旨是讓平台的各種元素能隨著時間變更與更新，同時支援現有和新產品。涉及產品生命週期的不同軟體供應商可能有各自獨立的開發和發布時間表。本文說明支援這項分離可更新性的機制。

平台可更新性如何運作？

Fuchsia 有多項機制可以促進平台隨時間更新的能力。以下我們調查了最主要的機制及其部分應用程式。

嚴格定義的介面

介面就像是不同軟體之間的合約。Fuchsia 定義了平台和其執行軟體之間的這類合約。平台的應用程式二進位檔介面 (ABI) 介面已事先定義並列舉。ABI 途徑包括進入核心的進入點、與平台服務的所有互動，以及其他慣例與通訊協定。開發人員可以編寫以 Fuchsia Integrator Development Kit (IDK) 為基礎的軟體開發套件 (SDK)，編寫可與 Fuchsia 互動的軟體。Fuchsia IDK 包含介面定義和用戶端程式庫，可提供根據相同平台合約衍生的應用程式設計介面 (API)。

介面定義語言

Fuchsia ABI 主要以 Fuchsia 介面定義語言 (FIDL) 定義。

FIDL 工具鍊可以為多種程式設計語言的用戶端與伺服器產生繫結程式碼。工具鍊旨在簡化支援更多語言的支援。

FIDL 旨在支援跨版本相容性並簡化介面變更。FIDL 具有相容性保證，並且具體列出哪些變更與二進位檔相容 (ABI 穩定版) 和/或原始碼相容 (API 穩定版)。

FIDL 具有介面定義語言，具有特殊用途，可協助開發人員隨時間變更通訊協定和類型，同時維持回溯和前瞻相容性。有時也稱為軟轉換。

Fuchsia 以 FIDL 定義大部分的 Fuchsia 系統介面，特別是預期會隨時間變動的部分，如此便能更有效地利用 FIDL 的特殊用途進行修正。

版本管理和相容性中繼資料

Fuchsia 定義「平台版本管理配置」，用來表示 Fuchsia IDK 和 Fuchsia 平台的 ABI 修訂版本。Fuchsia IDK 或 Fuchsia 平台的每個版本可能會分別導入 API 或 ABI 修訂版本，在這種情況下，該版本會以遞增版本指出。版本化版本可能會支援某一個範圍的回溯/前版相容性視窗。

Fuchsia 介面的屬性可以使用各自的版本管理中繼資料加註。

  • 屬性可以新增，也可能已在指定版本中移除。這會以編號版本定義該屬性的支援期。
  • 可能會在指定版本將屬性標示為「已淘汰」。「淘汰」表示最終會移除屬性，但不會影響 ABI。
  • 已淘汰的屬性可能會附帶額外的附註，這些附註必須採用人類可讀的格式。 通常該附註會向開發人員指示應採取哪些行動，避免在屬性移除後造成作業中斷。

介面中不同元素的註解方式可能不同。例如，在通訊協定或聯集欄位中的不同方法可能已在不同版本中新增、淘汰或移除。

FIDL 是 Fuchsia 上介面定義的通用語言，支援版本管理註解。為協助變更平台 FIDL 檔案的開發人員偵測其變更會對 API 造成不相容的修訂版本，系統會從 FIDL 檔案產生 API 摘要。您可以比較摘要與已儲存的參照 (例如黃金檔案)，找出破壞性變更，並確保這類變更是透過明確意圖導入。

命名空間

傳統上，「程序」是執行緒和受保護資源的容器，例如虛擬記憶體區域。在 Fuchsia 上，程序可能額外獲派本機命名空間。命名空間是「沙箱」sandbox的基礎，可確保程式只能根據所給的條款存取獲得的資源，例如以核心物件的形式存取，例如做為 FIDL 通訊協定，或以檔案形式存取。這些模組會形成程式在執行階段可以使用的不同capabilities。

沙箱通常是根據元件資訊清單定義。元件資訊清單組合可能會定義沙箱中存在的功能，以及如何滿足這些功能。不過，沙箱中的元件無法查看這些詳細資料。元件的父項可能會將能力轉送到由某個元件或其他元件提供的子項，隨著時間變更實作的詳細資料，但沙箱的形狀維持不變。

沙箱作業可促進鬆耦合，且可在客戶不知情的情況下變更實作詳細資料。舉例來說，Netstack3 取代 Netstack2 時，在理想情況下使用網路功能的元件不會注意到任何差異。這也有助於測試，因為測試作者可能會將「測試替身」插入元件，而未被測試的元件偵測。

套裝

套件是指 Fuchsia 上軟體發行的單位。套件包含指定目錄版面配置中的一或多個檔案。可能符合系統 ABI 的封裝慣例。

包裝作業能夠與名稱間距合作，藉此打造沙箱機制。從套件解析的元件將可以存取其命名空間中的封裝內容。因此，元件作者可能會將額外檔案與其元件套件，例如本地化資產。相反地，這些檔案通常不會直接從其他套件存取檔案。例如，系統字型是透過 FIDL 通訊協定提供，而不是直接存取檔案。或者，開發人員也可以自行套件字型檔案。

違規處置

如果可以規避兩個系統之間的特定介面，則這兩個系統的結構可能會更緊密，並失去了彼此之間獨立變更的能力。Fuchsia 使用各種機制來強制觀察並尊重平台介面。

  • 核心會定義 ABI，以便透過使用者模式程式碼 (即系統呼叫 ABI) 輸入核心。但 ABI 位於核心和 vDSO 之間。應用程式必須呼叫 vDSO 匯出的符號，而不是直接執行系統呼叫。由於核心和 vDSO 可能會同時建立版本，因此要求應用程式呼叫 vDSO 可讓系統呼叫 ABI 流暢變更，而不會遭到應用程式開發人員偵測。為了強制執行這個屬性，核心會在 syscall 進入點檢查呼叫端的地址，並確保該位址在呼叫端位址空間的對應 vDSO 範圍內。
  • 核心提供程序建立的系統呼叫。不過，程式載入詳細資料很複雜，因此在實作程序啟動器實作後會省略。為確保應用程式開發人員不會接觸到這些詳細資料，元件無法直接建立程序，而可能會改為提供設有 FIDL 通訊協定之後的程序啟動器。如此一來，程式載入的詳細資料會隨時間而變動。
  • 任何檔案系統目錄都可以做為程序命名空間的根目錄。這些命名空間可確保程式只能存取已知和列舉的檔案組合，防止程式形成非預期的 ABI。為確保目錄路徑能做為無法使用的根層級，Fuchsia 檔案系統便不會實作「..」。

其他資訊