As hvisor has grown, the per-board Cargo features list is no longer expressive enough to describe platform options reliably; we need a richer configuration model (Kconfig) with dependencies and a single source of truth.
hvisor enables platform capabilities (interrupt controller, UART, PCIe access mode, IOMMU, arch-specific options, etc.) like this:
- A large set of [features] in Cargo.toml
- Per-board lists in platform///cargo/features
- Makefile reads those via tools/read_features.sh and passes them to cargo build --features "..."
That approach has clear limits:
- No single configuration surface; no Kconfig-style depends on, select, or mutual-exclusion checks
- Board options are split between Cargo features and directory layout, unlike typical kernel/firmware workflows
- rust-analyzer --features often diverges from what CI and make actually build
- CI matrix jobs must maintain FEATURES (or equivalent) in sync with each board tree
As hvisor has grown, the per-board Cargo features list is no longer expressive enough to describe platform options reliably; we need a richer configuration model (Kconfig) with dependencies and a single source of truth.
hvisor enables platform capabilities (interrupt controller, UART, PCIe access mode, IOMMU, arch-specific options, etc.) like this:
That approach has clear limits: