14f0e4d0e2
Porting zsh found four defects in the kernel and one in the filesystem. None of them were about zsh; all of them had been there the whole time. **exec threw the environment away.** kernel/fs/exec.c wrote a single zero for envp with the comment "(no environment)" -- not yet, but ever, for every process. musl has been passing a perfectly good envp to execve (Linux 59, which SchOS answers) and it was never read. So $TERM was unset, $PATH was whatever each program invented, and a variable exported in a shell did not survive the exec meant to carry it. exec() takes an envp, sys_exec reads argument three, and schinit manifests grew an Environment key. The userland two-argument exec(path, argv) stays as a wrapper that passes null explicitly -- the raw stub is execve now, so a short caller cannot leave %rdx holding a stray pointer. **Which overflowed the kernel stack.** Three pointer arrays, ~1.8 KB, on a 4096-byte stack, under exec -> loaduvm -> readi -> SchFS -> btree. Pid 1 went down on the first exec. The canary caught it and named the process, which is what it is for. They live in one kalloc'd page now. **waitpid returned a bare -1** for both "no children" and "interrupted". musl reads [-4095,-1] as -errno, so userspace saw EPERM; zsh printed "wait failed: operation not permitted" and abandoned the rest of /etc/zsh/zshrc. -ECHILD and -EINTR now. Third time a bare -1 has cost real time -- on a system with no permission model, EPERM should be read as "a syscall returned -1". **NVMA was 64.** musl's allocator takes a mapping per size class and does not release them eagerly, so compinit ran out of slots and got -1, which is EPERM, which malloc turns into NULL, which zsh reports as "fatal error: out of memory" -- on a machine with 1000 MB free. 256 slots, and -ENOMEM. **And a small write to SchFS costs 58 ms.** 200 writes to one open file take 11.75 s; the same to /dev/null take 0.14 s. That is the design stated at the top of kmount.c -- one transaction group per operation, and a commit is two flushes and an uberblock -- not a bug. But compdump writes its digest with thousands of separate prints, so it takes minutes and looks like a hang. compinit -D, which skips the dump, finishes in 3.6 s. This one is a decision rather than a fix, so it is written up and left: /etc/zsh/zshrc keeps compinit switched off and explains exactly why, with the measurements. zsh runs as /bin/zsh and is the console shell. ZLE works -- arrow keys recall history through terminfo, $COLUMNS reads the real 160 because TIOCGWINSZ was fixed, colour and prompt expansion work, startup is 0.14 s. mksh keeps /bin/sh, so schinit's no-jobs fallback is a different program from the one that could have failed. Also fixed while here: AT_CLKTCK was the literal 100 and is USER_HZ; the extract rule in four ports could move a source tree inside itself when make re-ran it, which is how zsh's configure came to write modfile=zsh-5.9/... into config.modules and fail three steps later. schfs-check passes. Full writeup in docs/history/kernel.md section 14. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
68 lines
3.5 KiB
C
68 lines
3.5 KiB
C
#pragma once
|
|
|
|
// The timer interrupt rate the kernel is built around. Everything that turns
|
|
// ticks into a duration divides by this. It used to be the literal 100 written
|
|
// out at each site, which made it look like a fact about the hardware; it is
|
|
// not. It is a target, and kernel/arch/x86_64/lapic.c calibrates the LAPIC
|
|
// timer against the PIT to actually hit it.
|
|
#define HZ 100 // timer interrupts per second
|
|
|
|
// The tick rate the *user-space ABI* is defined in, which is a different thing
|
|
// from HZ and must not follow it. glibc and musl both answer sysconf(_SC_CLK_TCK)
|
|
// with a hardcoded 100, so times() and /proc/stat are read as hundredths of a
|
|
// second no matter what the kernel's internal rate is. Linux calls this USER_HZ
|
|
// and scales at the syscall boundary; so does SchOS, in the two places below.
|
|
#define USER_HZ 100
|
|
|
|
// Converting a POSIX timespec/timeval into ticks. These used to appear as the
|
|
// bare literals 10000000 and 10000 at each call site, where they looked like
|
|
// magic numbers rather than what they are: the length of one tick, expressed
|
|
// in the units the caller happens to be using.
|
|
#define NSEC_PER_TICK (1000000000 / HZ)
|
|
#define USEC_PER_TICK (1000000 / HZ)
|
|
#define MSEC_PER_TICK (1000 / HZ)
|
|
|
|
#define NPROC 128 // maximum number of processes
|
|
#define KSTACKSIZE 4096 // size of per-process kernel stack (increased for x64)
|
|
#define KSTACK_CANARY 0xDEADC0DEDEADC0DEULL // sentinel at kstack[0], see kstack_check_canary()
|
|
#define NCPU 16 // maximum number of CPUs
|
|
#define NOFILE 128 // open files per process
|
|
#define NFILE 512 // open files per system
|
|
#define NINODE 200 // maximum number of active i-nodes
|
|
#define NDEV 10 // maximum major device number
|
|
#define RAMDISK_DEV 2 // memory-backed block device (kernel/dev/ramdisk.c)
|
|
#define USBDISK_DEV 3 // USB mass storage (kernel/drivers/usb_storage.c)
|
|
|
|
// Device the root filesystem is mounted from. Building with RAMROOT=1 defines
|
|
// RAMDISK_ROOT and boots from the SCHFS image linked into the kernel instead
|
|
// of the IDE disk, leaving the physical disk free to be reformatted from a
|
|
// running system. See kernel/dev/ramdisk.c.
|
|
#ifdef RAMDISK_ROOT
|
|
#define ROOTDEV RAMDISK_DEV
|
|
#else
|
|
#define ROOTDEV 1 // device number of file system root disk
|
|
#endif
|
|
#define MAXARG 32 // max exec arguments
|
|
#define MAXENV 64 // max environment variables passed through exec
|
|
#define MAXPATH 128 // max path
|
|
#define MAXOPBLOCKS 30 // max # of blocks any FS op writes
|
|
#define LOGSIZE (MAXOPBLOCKS*3) // max data blocks in on-disk log
|
|
// Disk block cache, in blocks. 256 * BSIZE = 1 MB.
|
|
//
|
|
// Was MAXOPBLOCKS*3 = 90 blocks, and at the old 1 KB BSIZE that is a 90 KB
|
|
// cache -- smaller than the toybox binary that every single command execs. So
|
|
// nothing was ever still resident on the next command and each one paid the
|
|
// full read again. 1 MB holds toybox with room to spare, which is what makes
|
|
// the *second* command fast rather than just the first.
|
|
//
|
|
// Sized rather than maximised: these are statically allocated in bio.c, so
|
|
// this is memory the system always spends. 1 MB is affordable on a machine
|
|
// with tens of megabytes; 8 MB would not be.
|
|
#define NBUF 256
|
|
#define FSSIZE 150000 // size of file system in blocks
|
|
|
|
// Network interfaces the stack will attach. Two is already an ordinary machine
|
|
// -- a laptop with Ethernet plus a virtual adapter -- and each one costs a
|
|
// struct netif, so the limit is about keeping a fixed array honest rather than
|
|
// about memory.
|
|
#define NETIF_MAX 4
|