| RFC-0006：Zircon 的 RFC 程序增修條文 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 使用 Fuchsia RFC 程序處理 Zircon 時的特別注意事項。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2020-08-17 |
| 審查日期 (年-月-日) | 2020-09-25 |
摘要
本文提議改良 Fuchsia RFC 程序，以因應 Zircon 程式碼集帶來的挑戰。具體來說，如果對 Zircon 的變更符合下列一或多項條件，就必須先完成 RFC 程序，才能獲得接受。
提振精神
目前 Zircon 採用臨時程序進行全系統變更，但現在 Fuchsia 已有明確的 RFC 程序，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 程序及其演進保持一致，似乎是解決這些問題的最佳方式。