| RFC-0006：Zircon 的 RFC 程序附加條款 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 使用 Zircon 的 Fuchsia RFC 程序時的特殊注意事項。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 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 系統介面。系統呼叫介面、相關結構和常數是整個系統的真值，而且在實作前需要廣泛的共識。
變更資源處理行為。系統如何處理分區或虛擬化資源 (例如記憶體、I/O、處理器時間或能源使用量)，以及資源超額訂閱或過少時的處理方式。
修改隔離保證。相同工作中可觀察及修改哪些私人工作、其私密性及隔離程度。您需要在諮詢安全性團隊的過程中，透過這項程序核准此處的變更。
重大的效能或記憶體用量變化。有時，如果額外新增安全性、監控或功能，效能和記憶體用量會隨之降低，而這類情形就需要透過這項程序進行審查。
偏見單一平台。Zircon 致力於在所有支援的架構和主面板中擁有同等的功能和服務。如果是採用單一平台功能，但在其他支援的平台中無法可行或實施的變更，就需要使用這項程序。
新增或降級對特定平台的支援。新增主面板或架構，或是淘汰/減少對現有平台的支援，都需要透過這項程序進行審查。
新的建構設定。新增建構設定會增加整個專案的開發和測試負擔，且必須事先審查。
依附元件圖表大幅增加。Zircon 依附元件會影響整個專案及重大變更，例如，如果套件本身有重大依附元件，或在該套件中擁有較大的依附元件，則應使用 RFC 程序。
其他對 RFC 程序有益的變更，則是需要手動或自動化大規模變更程式碼集的變更。例如記錄寫入方式或錯誤路徑的處理方式。您的目標是找出最佳模式，並統一套用到整個程式碼集，而非分散在一致性的島嶼。
說明文件
這項 RFC 和 Fuchsia RFC 程序可做為適用於 Zircon 的 RFC 程序說明文件。
缺點、替代方案和未知
Fuchsia RFC 程序引進，可能會拖慢決策速度和執行速度。依照「使用程序的時機」一節中的條件，將程序範圍限定為可能的情況，試圖減緩此問題，但此類範圍界定會含有偽陽性和偽陰性。
來源存放區中的記錄決策，會導致這些決策更難以變更。在某些情況下，這種效果可能會呈現正面，但在其他情況下也有可能會造成負面影響。
可能的決策程序有很多替代策略，但要與 Fuchsia RFC 程序及其演進來解決問題，因為該策略目前看來是最佳方式。