cd812cc00e41b4f553faaa837140df47cda2cf72
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
a32eed877d |
Phase 2a: FAT engine mutations + O_TRUNC (fix the overwrite corruption)
The FAT engine could create, read, write, and grow files, but never free clusters or make directories — so overwriting a shorter file left a stale tail (a real bug: corrupt boot-log re-flushes, and later corrupt compiler cache/.o files). This adds the mutation half of the engine, with the corruption fix wired all the way through. Engine (system/services/fat/engine.zig), all host-tested: - freeChain: return a cluster chain to the pool (bounded against a corrupt cycle) — the shared primitive under truncate and remove. - truncate: free the chain and zero the entry's size/first-cluster (O_TRUNC). - createDirectory (mkdir): allocate + initialise a cluster with "." and ".." and add the directory entry to the parent. - removeFile (unlink): free the chain and mark the 8.3 entry plus any preceding long-name entries deleted, so a reused slot can't inherit an orphaned long name. Refuses directories. - createFile now shares a common addEntry helper with createDirectory. O_TRUNC wired end to end: a truncate open-flag (vfs protocol) that the router already forwards; runtime.fs.OpenOptions.truncate; and fat's handleOpen calls engine.truncate on an existing file. The boot-log flush (log-flush + init) now opens with truncate, so a shorter log on a later boot of the same stick leaves no stale tail — closing the caveat from the boot-log work. mkdir/unlink are engine-complete and host-tested but not yet exposed as VFS operations / runtime.fs methods (they are new path-based ops needing router cases); rename and the richer stat (mtime/mode, blocked on wall-clock) remain. See docs/zig-self-hosting.md (Phase 2). Verified: zig build, zig build test (8 engine host tests, incl. truncate, the overwrite-no-stale-tail regression, remove, and mkdir), zig build check-fat-image, and a sequential QEMU sweep — fat-mount, log-flush (DANOS.LOG read back at 11804 bytes, clean, with the truncate-based final flush), vfs, vfs-client-death, usb-storage, orderly-shutdown, initial-ramdisk, smoke — all green. |
||
|
|
347a041d85 |
Phase 1a: add the native runtime.fs, retire the posix shim
The first step of the Zig self-hosting roadmap (docs/zig-self-hosting.md): give danos programs a danos-native file API and remove the premature POSIX compatibility shim. This also resolves the earlier misplacement of a full-write helper into the compat layer — that behaviour now lives natively in runtime.fs.File.writeAll. - library/runtime/fs.zig: the danos-native file client over the VFS (open/read/ write/writeAll/seekTo/attributes/close, directory listing, mount). Handles are *values* — a File/Directory owns its VFS node id and byte offset — so there is no per-process fd table or descriptor limit, unlike the POSIX fd model the shim emulated. This is where the operations that later become std.os.danos are staged. - Retire library/posix/ (unistd, stdio): only five call sites used it, all file operations, all migrated to runtime.fs — fat (mount), the vfs-test and fat-test clients, and init/log-flush (the boot-log flush). stdio was already dead. - build.zig: drop the posix module, its addUserBinary parameter, the per-binary import, and the ~26 call-site arguments. - Docs: the VFS protocol's client is now runtime.fs; the docs index and coding-standards note posix is retired and the foreign-ABI naming exception now applies to the future std.os.danos seam; the process-lifecycle note points the future musl layer at that same seam rather than the deleted directory. Deferred by design (see the roadmap): the C-ABI runtime.os errno seam is built at fork time (its shape must match std/os/danos.zig); truncate/mkdir/rename are Phase 2; stdio-byte fds and cwd are later slices. Verified: zig build, zig build test, zig build check-fat-image, and a sequential QEMU sweep — vfs, vfs-client-death (the park/hold-handle path), fat-mount, log-flush, orderly-shutdown, initial-ramdisk (log-flush silent in the bare sweep), smoke, init, usb-storage, device-manager — all green. |
||
|
|
f52c591f5e |
Persist the kernel boot log to the USB FAT volume
On a headless or real board nothing captures serial, so the boot log — the whole diagnostic stream — is lost at power-off. This retains it in the kernel and copies it to the boot USB volume as /mnt/usb/DANOS.LOG, the on-disk equivalent of QEMU's `-serial file:`. Pull the stick, read DANOS.LOG on another machine. How it fits together: - Kernel RAM sink (log.zig): a fixed 256 KiB in-image buffer registered as a log sink in kmain, right after serial. Because userspace debug_write funnels through log.write, it captures the entire stream — kernel lines and every service's output — from the first line. Fills linearly and stops when full (earliest boot output, the most valuable, is kept); no allocation, so it is panic-safe. - klog_read syscall (32): copies that buffer out to a user buffer, the mirror of debug_write — same overflow-safe user-half bounds check, kernel -> user copy, under the kernel lock so the snapshot can't grow mid-copy. Wrapped by runtime.system.klogRead. - log-flush (new one-shot, in the initial-ramdisk): waits for the fat server to mount /mnt/usb, then copies the whole log to /mnt/usb/DANOS.LOG. init spawns it once the boot services are up (fire-and-forget; it polls the mount itself). If no volume is mounted — no stick, or the no-VFS ramdisk sweep — it exits silently. - init shutdown flush: init repeats the copy inline at the top of shutDown(), BEFORE it tears down the storage services (the fat server is stopped first), so a clean poweroff captures the fullest log while /mnt/usb is still writable. - unistd.writeAll: loops write() past the 224-byte VFS payload cap; both flush paths use it. The filename is 8.3 (DANOS.LOG) at the mount root — the FAT short-name rule, and there is no mkdir on the FAT path yet. Extend-only writes mean the two same-session flushes never leave stale bytes (the shutdown log is a superset of the boot log); a shorter log on a later boot of the same stick can leave a stale tail — a noted, cosmetic limitation, not worth pulling O_TRUNC into the FAT write path for now. Verified end to end under QEMU: a new `log-flush` case (reusing the orderly-shutdown build) asserts both markers then S5, and DANOS.LOG is read back out of the image afterwards (11804 bytes, containing the kernel init line, the FAT mount line, and the boot flush marker). Regression stays green: zig build, zig build test, zig build check-fat-image, and a sequential QEMU sweep — smoke, init, initial-ramdisk (log-flush silent in the bare sweep), orderly-shutdown, fat-mount, usb-storage, usb-hid, vfs, input, device-manager, process, signals, dma, fault-pf. |