審查 Diosix
Diosix 中的每一項程式碼和文件變更在提交或合併之前,都必須通過嚴格、多角度的稽核。請勿對變更草率放行,也絕不能簽署損壞、不完整或未經驗證的程式碼。以下審查標準與 developing-diosix 和 documenting-diosix 1:1 對應,因此套用作者技能可消除提交前與合併前的重工。
強制性 4 步驟驗證工作流程
- 建置、完整性與測試門檻(基本要求):
- 驗證功能是否已按設計 100% 實作,且無任何
TODO存根、死程式碼或模擬的生產路徑。 - 重構超過 500 行限制的檔案時,永遠不要截斷功能或單元測試;始終將過大的檔案元件化為具凝聚力的子資料夾(例如
vm/run.zig、panes/modal.zig、tests/gui.zig),而不是使用扁平的prefix_subname.zig檔案,並驗證每個子模組都在其父級的test區塊中被引用(例如_ = @import("vm/run.zig");),確保zig build test能執行其單元測試。 - 驗證單元測試與被測的
.zig原始檔置於相同位置,而整合測試則位於獨立的tests/目錄中。 - 將檔案格式及行/欄檢查的範圍限定在受追蹤的原始碼目錄(
build.zig、hypervisor、tools、scripts),而不是對.zig-cache/或zig-out/執行無範圍限制的遞迴全域搜尋。 - 執行
./scripts/build.sh test --summary all和./scripts/build.sh,直到所有編譯和測試步驟 100% 通過且無任何警告或記憶體洩漏。
- 驗證功能是否已按設計 100% 實作,且無任何
- 4 角色深度審查:
- 透過四個不同的視角稽核每個修改過的檔案及其周圍的上下文:
- 持懷疑態度的資深工程師(完整性、慣用寫法、子資料夾層次結構而非扁平化的
prefix_subname.zig檔案、小寫十六進位字面值0xfff、使用具名常數/輔助函數如PAGE_OFFSET_MASK和crossesPageBoundary而非魔術位元遮罩、無Spinlock/對齊/路徑驗證器的複製貼上重複、無像DEFAULT_GUEST_CANDIDATES這樣的歷史候選列表後備陣列用於共同版本的內部路徑、顯式的固定寬度u64ABI 類型而非usize、在@min/@max與字面值搭配使用時顯式添加usize類型註解、元件化超過 500 行的檔案時不截斷內容、<=80 欄的限制、動態 vs. 靜態緩衝區、將策略外部化到建置/執行時期配置、不在 Zig 中即時合成二進位檔/ELF/映像檔、不在tools/overlay-common/內產生檔案) - 偏執的安全專家(Hypervisor 爆炸半徑隔離、對客戶記憶體進行單次複製雙重提取/TOCTOU 預防、透過
atomic.Spinlock實現 IRQ 安全的鎖定、加密/頁面歸零、檢查算術邊界) - Diosix 維護者(模組化、可讀性、
defer/errdefer、ABIcomptime大小/偏移量斷言、外部合約向後相容性 vs. 原子化的樹內遷移、子模組測試覆蓋率) - 初學者與專家使用者(零繁瑣使用者體驗、清晰的英文錯誤訊息、設定靈活性、效能)
- Rust 風格的借用檢查器與指標生命週期稽核:
- 手動追蹤所有控制流程路徑上的每個指標、切片和分配,以保證零釋放後使用(UAF)、雙重釋放、調整大小/重新映射時的指標失效,或懸空堆疊參考。
- 文件、拼寫與風格門檻:
- 驗證
docs/與所有程式碼變更(包括 SBI FIDs、C 結構體類型、CLI 標誌和模組化後的檔案路徑)相符,內容以語法正確且拼寫無誤的清晰美式英文撰寫,並遵守docs/style-guide.md和docs/development.md。 - 在任何審查修正後,重新執行
zig fmt --check build.zig hypervisor tools scripts和./scripts/build.sh test --summary all。
- 驗證
- 不確定時,暫停並詢問首席維護者:如果審查發現架構上的取捨或缺少的基本功能,請暫停並向首席維護者請教方向,切勿自行假設。
聚焦參考指南
每次審查時請參考這些檢查清單:
- 4 個審查角色檢查清單:針對持懷疑態度的資深工程師、偏執的安全專家、Diosix 維護者以及初學者/專家使用者的詳細檢查標準。
- 借用檢查器稽核:在 Zig 中追蹤指標來源、生命週期、別名可變性以及跨權限記憶體安全性的逐步方法論。
- 提交前門檻:提交或合併至
devel或stable分支前所需的具體驗證指令與簽核標準。