| 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 的敏感度遠高於專案葉節點附近的程式碼 (例如大幅增加依附元件圖表，或記憶體用量與效能的平衡方式)。
設計
絕大多數 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 程序及其演進保持一致，以解決這些問題，是最好的前進方式。