Implementation Progress (Macro Areas)

Last review: 2026-09-29

One row per area, the state in a sentence or two. How each got there is in the linked files, which keep the full history - including the long status cells this table used to carry, moved there verbatim on 2026-09-29.

Macro AreaStatusDetails
Review FindingsTracked through M-083. Open: M-068, M-070 (instrumented, unexplained; not seen since the stack grows on demand), M-080 (a descriptor's calls walk a path: mitigated with ESTALE, not closed) and M-081 (the page cache's file identities are never given back: 512 of them now, and it says when they run out) and two internal families, the four-worker thread crash and rmap_mismatch.review_findings_tracker.md
BootloaderCompleted (boot-to-CLI verified).bootloader.md
Kernel CoreCore plan C0-C7 done (2026-09-27), C5's residue closed (M-071..M-073). Blast radius 1 for every device kind, syscall 2 by decision. See core/phases.md.kernel_core.md core_plan_revision.md core_perf_baseline.md core_c1_checks.md external_reviews_verified.md core_dead_code.md core_c1_blast_radius.md core_c2_observability.md review_sixth_verified.md mm_tlb_quarantine.md review_seventh_verified.md mm_brk_mmap_leaks.md uaccess_recovery_open.md core_c5_process_state.md pipe_eof_race_open.md core_c4_abi.md
Boot Repeatability24 of 24 clean on the reference configuration, from a long-standing 1 in 8; every boot gate check is sabotage-proved.boot_repeatability.md
Tasks and SchedulingS-P0 to S-P6 done: a transition table that refuses illegal changes, tenancy on every reference, classes and nice-weighted fairness, an enforced quantum, a fork and clone guard. Threads share their process's state and descriptors (M-072). See docs/sched/.sched.md process_scheduler.md sched_quantum_threads.md sched_torture.md
Memory ManagerP0-P6 done (ADR-0007): frame layer, reverse map, copy-on-write with TLB shootdown, watermarks and pinning, compaction, swap to a file with a second-chance clock. The reclaim path runs every boot (svc-reclaim, including a teardown racing it). See docs/mm/.memory_manager.md cow_stale_page.md mm_rmap.md mm_reclaim.md mm_compaction.md mm_swap.md mm_acceptance.md mm_demand_paging.md mm_frame_init_flags.md mm_soak.md mm_latency.md mm_swap_file.md lock_deadlock_bound.md console_lock_bound.md detector_checks.md A failure the gate was naming wrongly, found while chasing the argv one: three boots in ten failed as stress_run_did_not_finish and the stress run had finished - 120 rounds, exit 0, machine healthy to the CLI. What went missing was its marker, and all three logs held the same bytes: sixteen NULs then =120, where STRESS_OK rounds is exactly sixteen characters. A user stack buffer whose first sixteen bytes the kernel read as zero. interleaved_lines is not at fault - its docstring already states the limit that let this through - so a separate check names the mechanism now (mm_ring3_write_nul.md). Narrowed hard: the copy-on-write copy is faithful (a fold of the page before and after every resolution, cow_copy_changed=0), the page faults several times in the same process rather than once as a comment in the tree claimed, and the defect needs more than one core - eight boots at -smp 1 produce zero corrupted writes against three to five in ten at four. The process migrates, measured on both sides. The explanation that fits every symptom - a stale writable TLB entry surviving a fork that sent no shootdown because the process is single-threaded - is refuted by one grep: there is no PTE_GLOBAL and no CR4.PGE in this tree, so every CR3 write flushes. The mechanism is open and the candidate list is written down (mm_lost_store_smp.md). Four explanations for the argv defect were instrumented and closed on the way - the desktop's buffer cannot reach the low user window (pmm_reserve truncates the region), the framebuffer is outside managed RAM, a canary shows no overrun, and no frame of it is shared or lost - and the question that file named as its next step was already answered by double_allocs, a counter nobody had connected to it. The argv defect did not reproduce in eighteen boots against a recorded rate of one in six. ROOT CAUSE FOUND AND FIXED: the kernel set CR4.OSFXSR, uses 6955 XMM instructions of its own, and contains zero fxsave/fxrstor/xsave - so a user task's SSE registers survive a syscall, an interrupt or a context switch only by luck. clang stores 16-byte stack buffers with movdqa, which is why the corruption was always exactly sixteen bytes - one XMM register - a width nothing in the memory manager could explain. The zeros are not a fresh page: svc-stress forks a hundred children running a binary that opens with pxor %xmm0,%xmm0. And it explains the argv vector too: COL_TITLETXT is 0x00FFFFFF, the desktop paints from the kernel on interrupts, and a vectorised fill leaves two white pixels in a lane pair that the resumed task stores into its own buffer - the desktop never touches that memory, which is why every memory counter read zero and was right. Ten hypotheses were measured and killed first, all of them in the memory manager because the symptom looked like memory (mm_no_fpu_context.md). Fixed, in two halves. The context switch saves and restores a 512-byte per-task area (eager, not lazy: CR0.TS needs a fault handler, per-core ownership and cross-core invalidation, three mechanisms on the path this kernel has the most defects in); the initial state is built by hand because MXCSR at offset 24 reads zero as unmask every SSE exception; fork copies it, threads get a clean one, and CR4.OSFXSR is set on the boot processor too - only ap_boot.S ever set it, so the BSP had it because UEFI leaves it on. That half alone took the corruption from three boots in ten to one in twelve, which is the number that would have been called a fix on a five-boot sweep. The second half is -mno-sse on the kernel, as Linux does: a syscall returning to the same process never reaches the scheduler, so nothing saves anything. 22 boots: 0 corrupted writes, 0 xmm lost, host tests and boot gate green. One near-miss recorded: the first attempt gated the flags on if(IMAGE AND NOT TESTS), and both are on in every real build - it would have compiled to nothing while looking like a fix. Open: the argv vector that is not a pointer reads 0x00ffffff00ffffff - two white pixels, COL_TITLETXT from the GUI - and the same value turned up independently as an out-of-range sector in the block layer. The desktop is painting over memory somebody else owns, which is a recurrence of a defect the code comments already describe, and it explains why every memory counter is zero: nothing is freed early, frames are handed out twice (mm-argv-poison.txt). Two detector defects were fixed on the way: the mapper count was a global two cores overwrote, and the free-side check samples one free in sixteen, so its zero was being read as evidence.
Program LoadingX-P0, X-P1, X-P3, X-P4 done; X-P2 partly: image pages come from the page cache and the staging buffer is 128 KiB, demand paging of images is open. See docs/exec/.exec.md exec_silent_failure.md
Splitting arch_hw.cDone (2026-09-29): 12,174 lines before C4, 1,792 now - the CPU, the locks, the IDT, the trap handler and early init. The rest is in mm_bridge.c, task_life.c, task_switch.c, smp.c, userland.c, diagnostics.c, net_bringup.c and io_bringup.c.arch_extraction.md
Interrupt HandlingIn progress: CPU traps, the LAPIC timer on every core, IO-APIC routing, disk and network interrupts verified.interrupt_handling.md
System Call InterfaceIn progress: 74 Linux syscalls through one table-driven dispatcher, pointer arguments declared per row (C4). The plan for all 373 is docs/abi/; A0 is done (25 workloads, 1,530 LTP tests as an oracle - abi/corpus.md) and A1: one registry of every number, which the kernel answers from when there is no row (refused is counted, missing and deferred fail the gate by number). A2: the handlers reach the kernel only through include/vibeos/ksvc.h - a services interface meant for every personality, Windows included - and run in the host tests on a fake of it, with every partial row's gap written as a failing expectation. A3: descriptors name counted open file descriptions - dup and fork share an offset, 1024 per process, close-on-exec, dup3/fcntl/close_range - and each file type (file, directory, pipe, socket, console) has its own operations in kernel/abi/files/, shared by every personality. A4: paths - a working directory and root per process, one walk through the mount table (kernel/fs/path.c), dirfd honoured, cd in the shell gated, and the interpreter substitution deleted: the loader is found at /lib/ld-musl-x86_64.so.1, which needed FAT long names. A5: every Linux structure and constant the handlers use is declared once (include/vibeos/linux_layout.h) and compared - 232 comparisons - with the host's own uapi headers, and a check refuses a declaration the test does not compare. L1 (files and paths) is under way in eight steps, the filesystem first: the VFS has the operations a POSIX filesystem needs and one walk that follows symbolic links (step 1), and tmpfs - modes, owners, links, sparse files, rename-over - is mounted at /tmp with a nightly torture against a model (step 2); regular files write at their offset with open's flags as Linux means them, and twenty file calls - pread/pwrite and the vector forms, truncate, fsync, fallocate, sendfile, copy_file_range, umask - are served (step 3); FAT writes in place - offsets, truncate, long names created, rename, rmdir, growing directories - checked against mtools and a consistency checker, on the host and on the volume each boot leaves behind, and the whole-file write path is gone (step 4); names and metadata - stat, statx, access, rename, rmdir, link, symlink, the chmod, chown and utime families, statfs, mknod, openat2 - thirty-two rows, 108 of 373 done (step 5); record and whole-file locks with deadlock detection, directories listed with whole names, real types and inode numbers through getdents64 and getdents, the xattr calls answering as a filesystem without them does - 124 done (step 6); the console is a terminal with canonical and raw modes, so BusyBox's shell runs interactively at boot, with a minimal poll ahead of L4 (step 7); the corpus's fifteen file workloads - BusyBox's applets, SQLite, Lua - run at boot and are compared line for line with what Linux printed (step 8). L1 is closed; its LTP tests wait for L3's file-backed mappings. L3 (memory) is under way in six steps: mmap honours MAP_FIXED, hints and private file mappings (step 1); shared mappings stay shared across fork and a shared mapping of a tmpfs file is the file's own pages, with msync (step 2); LTP's 382 tests for L1 run (step 3: 131 passed, 10 failed, 177 broken, 57 not applicable, 7 did not run), which needed /proc, /etc/passwd, nanosleep and SA_RESTART, and found eight defects in L1's calls, fixed; madvise, mincore, the mlock family, mremap and memfd_create (step 4); the user stack grows on demand, two megabytes of it, with four pages mapped at exec (step 5, taken early); SQLite and Lua run built against glibc and dynamically linked, and SQLite runs in WAL mode with memory-mapped I/O (step 6). L3 is closed; its gaps are named in the registry. L7 (IPC) is closed (2026-10-12) in six steps: System V message queues, semaphores and shared memory with Linux's numbering and permissions, a segment an unnamed tmpfs file and its attach count read off the processes' regions; POSIX message queues; splice, tee and vmsplice over a pipe that can be looked into; /proc's first writable files, the IPC tunables (steps 1 to 5); a producer and consumer over SysV IPC under musl and glibc compared with Linux, whose LTP run found vmsplice waiting for room Linux does not wait for (step 6). LTP 64 of 81 from 0; what is left is netlink, a 4 KiB pipe, a tick-long sleep, or not x86-64's. L6 (threads and scheduling) is closed (2026-10-12) in four steps: the rest of futex, the futex2 calls and robust lists (step 1); the sched_* calls over a new real-time class, affinity, getcpu, ioprio and membarrier (step 2); clone making a process on its parent's memory - posix_spawn and vfork - with CLONE_PARENT, the tid words, and a task table of 64 (step 3); a thread pool under musl and glibc compared with Linux, which found that a fatal signal ended one thread instead of the process, that the TLB quarantine leaked when full, and that the mm lock's waiters did not answer a flush (step 4). LTP 53 of 67 from 16. L5 (sockets) is closed (2026-10-06) in four steps: the rest of the BSD calls on a neutral socket interface every personality can fill (step 1); AF_UNIX stream sockets, named in the filesystem or the abstract namespace (step 2); datagrams and SCM_RIGHTS on counted descriptions (step 3); BusyBox wget against the host, a DNS lookup through musl, a Unix-socket server and client at boot - and, from the phase's LTP run, a loopback the stack never had, and a half-closed connection that lost its slot under an open descriptor (step 4). LTP 44 of 64. L4 (event loops) is closed (2026-10-06) in seven steps, planned from what BusyBox's httpd, nc and tail -f ask for: poll, ppoll, select and pselect6 on one engine, with sockets saying what they can do (step 1); eventfd, timerfd and signalfd as file types that poll sees (steps 2 to 4); epoll - level, edge, one-shot, nested - on the same engine (step 5); inotify from one place in the file layer every filesystem passes (step 6); the programs themselves at boot - tail -f, httpd served to the host, nc both ways - which needed setsockopt and shutdown from L5 and found an endless loop in the TCP stack's flush (step 7). LTP for the phase: 58 of 83, the rest mostly socketpair and AF_UNIX (L5), setting the clock (refused) and resources the run does not stage. L2 (processes, credentials, time) is closed in seven steps: the programs - BusyBox's traps, timeout, ps and time compared with Linux, a stop that holds, orphaned process groups hung up (step 7); /proc about processes, /dev and getrandom (step 6); waiting by group and waitid, pidfds, clone3 and execveat (step 5); resource limits, five of them enforced, priorities and personality - and the scheduler's policy running on the machine for the first time (step 4); timers - alarm, interval timers and POSIX timers, fired by the tick (step 3); signals are delivered as Linux delivers them, with a siginfo and a ucontext, faults go to a handler that asked, and SIGCHLD is raised (step 2); a process has credentials, the sixteen calls that read and change them, and L1's file operations ask who is asking (step 1; LTP's L1 list after it: 154 passed (131 before it), 16 failed, 144 broken, 65 not applicable, 2 did not run. What is left is mostly a loop device, alarm, and files under /proc and /dev.).system_call_interface.md
IPC SubsystemIn progress: pipes and futexes on the machine; the native IPC is a host model.ipc_subsystem.md
Driver FrameworkIn progress: virtio-blk, AHCI, virtio-net, PS/2 keyboard and mouse, framebuffer - registered devices (C7), both disk controllers gated.driver_framework.md
Filesystem LayerI0-I6 done, I7 nearly: FAT read-write on the boot volume; ext2, ISO9660, NTFS and exFAT registered and gated from images the host's own tools built; partition tables, a mount table, a journal, a log disk. See docs/io/.filesystem_layer.md io_blkdev.md io_read_contract.md io_one_cache.md io_writes_proved.md io_volumes.md io_mounts.md io_parttab.md io_gpt.md io_ext2.md io_iso9660.md io_ntfs_exfat.md io_logsink.md io_boot_disk.md
Networking StackIn progress: IPv4, ARP, ICMP, UDP, TCP (RFC 5961 resets), DHCP and DNS; a DHCP lease and a TCP round trip gated every boot.networking_stack.md
User Space InterfaceIn progress: unmodified Linux binaries from ring 3.user_space_interface.md
Diagnostics & ObservabilityIn progress: runtime detectors, a must-be-zero registry and a persistent log disk, all gated; the checks are themselves checked (anchors, assertions covered, counters produced).diagnostics.md
Init SystemIn progress: native init is PID 1 and supervises a service manifest - start, stop, bounded restart, and a crash the kernel survives.init_system.md
Linux CompatibilityIn progress: static, PIE and dynamically linked musl binaries run and are gated - BusyBox, a shell, threads, signals, sockets.linux_compatibility.md
Windows CompatibilityW2 done (2026-10-17): Wine's own conformance tests run on VibeOS, on our ntdll (system calls, a DLL loader with named stubs for what is missing, the Rtl runtime), msvcrt and kernel32; the kernel has the object manager (handles are descriptors with access masks), events, mutants, semaphores, the waits, Sleep and image sections. ntdll:om, ntdll:sync and kernel32:sync run and report failures until they reach threads and timers, which are W5's. W3 done (2026-10-21): memory reserved and committed, made on first touch; NtAllocate/Free/Protect/QueryVirtualMemory and kernel32's VirtualAlloc family; a process heap that grows, with msvcrt's malloc on it; an image's .bss left to the page fault; data sections and their views; and the reviews' M-106, M-100 and M-108 fixed. kernel32:virtual runs without a failure until CreateProcessA (W6); ntdll:virtual, since NtAllocateVirtualMemoryEx and its placeholders (2026-10-22), until test_NtMapViewOfSection needs files (W4), failing only checks that need a low arena or write watches. W4 done (2026-10-26): files - NtCreateFile and the file services around it, names without case and beyond ASCII, share modes and mandatory byte-range locks, and kernel32's file API over them; ntdll:directory runs to its end, ntdll:file stops at APCs (W5). Plan: abi/windows.md.windows_compatibility.md
macOS CompatibilityNot started (same, and deliberately dormant).macos_compatibility.md

Notes

  • Status reflects code currently present in repository, not only planned milestones.
  • A file existing under user/compat/ is not progress. The Windows and macOS translators are twenty-four lines each, know two syscall numbers, and nothing calls them; they are tracked as not started for that reason. The Linux compatibility that works is the kernel syscall layer, which is a different piece of code entirely.
  • "Verified" here means a gate fails if it regresses, unless the entry says otherwise. The framebuffer desktop is the standing exception: its serial-visible state is gated, its pixels are checked by hand with scripts/dev/screenshot.py.
  • Each macro-area file contains:
    • implemented items verified in code
    • pending items
    • next execution checkpoint