Fuchsia 平台可更新性

什麼是平台更新？

產品需求會隨時間而改變，因此 Fuchsia 必須能夠配合新規定加以修改。

新的平台版本可能會提供新功能及修正錯誤。與 Fuchsia 平台整合的產品負責人之後，可能需要以新的平台版本重新建構現有產品組合。根據產品的性質和更新方式，使用者甚至可能直接從 Fuchsia 專案收到平台更新。視組合產品的性質而定，產品擁有者可能無法將現有應用程式軟體移植到新的平台版本，而且必須依賴預先建構的現有應用程式繼續搭配預先建構的新平台運作。

Fuchsia 的設計理念是讓平台的各種元素隨時間變更與更新，同時支援現有和新產品。參與產品生命週期的不同軟體廠商可能會有各自獨立的開發和發布時間表。本文說明支援這種可分離的更新機制。

平台可更新性的運作方式為何？

Fuchsia 有多個機制會促進平台的更新能力。以下我們將調查最醒目的機制及部分應用方式。

經過嚴格定義的介面

介面是不同軟體之間的合約。Fuchsia 針對平台與其執行的軟體制定這類合約。平台的應用程式二進位檔介面 (ABI) 介面已明確定義並列舉。ABI 介麵包含核心進入點、與平台服務的所有互動，以及其他慣例和通訊協定。開發人員可以編寫與 Fuchsia 互動的軟體，例如使用以 Fuchsia 整合商開發套件 (IDK) 為基礎的軟體開發套件 (SDK)。Fuchsia IDK 包含介面定義和用戶端程式庫，可提供應用程式設計介面 (API)，衍生自相同平台合約。

介面定義語言

Fuchsia ABI 主要根據Fuchsia 介面定義語言 (FIDL) 的定義。

FIDL 工具鍊可使用多種程式設計語言產生用戶端和伺服器的繫結程式碼。這項工具旨在讓您輕鬆擴充支援更多語言。

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

FIDL 屬於介面定義語言，可提供特殊功能，協助開發人員隨著時間變更通訊協定和類型，同時維持回溯與前瞻相容性。這類轉換有時也稱為「軟性轉場」。

透過在 FIDL 中定義大部分的 Fuchsia 系統介面，特別是預計會隨時間變更的部分，Fukesia 可以更妥善利用 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 無縫變更，不讓應用程式開發人員偵測到。為了強制執行這項屬性，核心會在系統呼叫進入點檢查呼叫端的地址，並確保 vDSO 落在呼叫端位址空間中對應的 vDSO 範圍內。
  • 核心提供建立程序的系統呼叫。不過，程式載入細節相當複雜，所以不需在程序啟動器實作後方完成這項作業。為確保應用程式開發人員不會揭露這些詳細資料，元件不得直接建立程序，而是提供採用 FIDL 通訊協定的程序啟動器。如此一來，程式載入的詳細資料就會隨著時間變更。
  • 任何檔案系統目錄都可用來做為程序命名空間的根目錄。這些命名空間可確保程式只能存取已知且列舉的檔案組合，避免檔案形成非預期的 ABI。為確保目錄路徑能做為強大根層級，Fuchsia 檔案系統不會實作「.」。

其他資訊