| RFC-0006：Zircon 的 RFC 程序補充說明 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 針對 Zircon 使用 Fuchsia RFC 程序時的特別注意事項。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2020-08-17 |
| 審查日期 (年-月-日) | 2020-09-25 |
摘要
本文提出了 Fuchsia RFC 程序的改善方案，考量了 Zircon 程式碼庫的挑戰。具體來說，如果對 Zircon 的變更符合下列一或多項條件，就必須遵循 RFC 程序才能通過。
提振精神
目前 Zircon 會使用臨時程序進行全系統變更，但現在 Fuchsia 已提供明確的 RFC 程序，Zircon 應遵循這項程序。不過，由於 Zircon 位於軟體堆疊的底層，因此相較於位於專案葉節點附近的程式碼，Zircon 對某些類型的變更更為敏感 (例如大幅增加依附元件圖表，或如何平衡記憶體用量與效能)。
設計
Zircon 的絕大多數變更都不需要 RFC，程式碼審查應該就足夠了。不過，除了 Fuchsia RFC 程序中列出的考量因素外，來源目錄中的變更還包括：
- /zircon
- /src/zircon
- /src/bringup
符合下列條件的應用程式必須使用 RFC 程序：
新增或移除 Zircon 系統介面。系統呼叫介面、相關聯的結構和常數是整個系統的基礎，對 Zircon 本身以外的影響範圍很廣，因此需要廣泛的共識才能實作。
變更資源處理行為。系統如何處理分割或虛擬化資源 (例如記憶體、I/O、處理器時間或耗電量)，以及在資源超訂或不足時的處理方式。
修改隔離保證。如何在同等工作中隔離私人和專屬工作，以及哪些特權工作可以觀察和修改。這裡的變更必須經過安全性團隊諮詢，並透過這個程序核准。
效能或記憶體用量發生重大變化。有時，新增安全性、監控或功能時，效能會隨之降低，或記憶體用量會增加，這需要透過這個程序進行審查。
偏好單一平台。Zircon 致力於在所有支援的架構和電路板中，提供相同的功能和服務基準。如果變更可運用某個平台的功能，但無法在其他支援的平台上實現或實用，就必須使用這個程序。
新增或降級平台支援功能。如要新增新的電路板或架構，或是淘汰/減少對現有平台的支援，都必須透過這個程序進行審查。
新建構設定。新增建構設定會增加整個專案的開發和測試負擔，因此需要事先審查。
依附元件圖表大幅增加。Zircon 依附元件會影響整個專案和重大變更，例如套件的新依附元件本身具有重大依附元件，或本身就很大，應使用 RFC 程序。
其他可能會受益於 RFC 程序的變更，是指需要手動或自動化大規模變更程式碼庫的變更。例如記錄的寫入方式或錯誤路徑的處理方式。我們不希望出現不一致的情況，而是希望找出最佳模式，並將其統一套用至整個程式碼基底。
說明文件
這份 RFC 與 Fuchsia RFC 程序可做為適用於 Zircon 的 RFC 程序說明文件。
缺點、替代方案和未知事項
Fuchsia RFC 程序會引入摩擦，可能會減緩決策和執行決策的速度。「何時使用此程序」一節中的標準會將程序的範圍限制在後續情況，以便緩解這項問題，但這類範圍必然會出現偽陽性和偽陰性。
在來源存放區中記錄決策會導致這些決策更難以變更。在某些情況下，這可能會帶來正面影響，但在其他情況下，也可能會帶來負面影響。
雖然管理決策程序有很多可能的替代策略，但目前看來，與 Fuchsia RFC 程序保持一致，並隨著其解決這些問題而持續演進，似乎是目前最好的做法。