STATUS.md/TASKBOARD.md under-reported several subsystems that are in fact
implemented. Corrected against the code and against a clean QEMU boot log
(.build_tmp/qemu_final.log, this branch).
- 页表映射接口 was ⬜ "mmio 通用映射待做". It exists and is in use:
kernel_api.mm_map_mmio / mm_unmap_mmio (PCD|PWT independent window), called
by apic, ehci, xhci and nvme, including BARs above 4G. -> ✅
- NVMe was 🔶 "PCI discovery only, BAR0>4G 待映射". CODE/DKM/nvme/nvme.c is
1641 lines: admin SQ/CQ with phase bit, IDENTIFY, IO queue (qid=1), read/
write/flush, cross-page PRP lists, MSI and MSI-X (vector allocator, IDT pool
0x40-0xDF), block provider registration, NVME-E01..E03 zero-fallback
instrumentation. -> ✅
- virtio_net was 🔶 "PCI/capability 枚举, 无 virtqueue". It has a legacy
split-ring virtqueue (desc/avail/used), vq_setup, 32x2048B RX buffers, TX/RX
rings and a DHCP DISCOVER->OFFER selftest. -> ✅
- ELF64 .drv loading said 14/14. build.ps1 now compiles all 17 drivers listed
in manifest.json (fixed on this branch; nine were never built since 055c521
untracked the .drv binaries). -> 17/17
- FAT32 (DKM side) stays 🔶 but the boundary was wrong. It is read-only
BPB/FAT/dirent parsing plus a root-directory walk, with no filesystem API
layer (no open/read/stat) - not "子目录路径待完善". The large-disk read/write
path lives in the DSK-side FAT32 implementation.
- TASKBOARD 遗留工程债: vector allocator/MSI-X, NVMe high BAR MMIO and
virtio-net virtqueue RX/TX are done. The remaining FAT32 item is reworded to
what is actually missing (the FS API layer).
Evidence for the driver/NVMe/virtio rows is the boot log on this branch:
14x "[<drv>] driver ready", and with no NVMe controller / virtio-net device
attached the drivers correctly log a warning and still reach "driver ready"
(designed fallback, both listed in the CLAUDE.md whitelist).
boonxiong2
cf395474bf