| Filename | Latest commit message | Latest commit date |
|---|---|---|
The network thread waited on the timer and nothing else, so a frame that landed just after a poll sat in the ring for up to 10 ms -- the largest fixed latency in the system. That was deliberate when the stack was new (a receive path woken by an interrupt is much harder to debug than one that is asked) and there is now a working stack to compare against, which is exactly when it becomes safe to do. The frame is still *pulled* by the thread through .receive. It has to be: a call into lwIP can reach the driver, the driver can sleep on the buffer cache, and an interrupt handler may do neither. netdev_rx_signal() delivers nothing and reads no ring -- it only ends the wait early. The wait stays on the timer tick rather than moving to a channel of its own, and that is the design. lwIP's timers must still run when the link is silent, so the clock has to remain a floor under the wait, and sleep() cannot wait on two things at once. Joining the tick's existing wakeup costs nothing and leaves one wait with one predicate. rx_signal lives under tickslock for the same reason it gets no lock of its own: sleep() releases tickslock atomically, so a driver setting the flag and waking under that lock cannot lose the wakeup by arriving between the predicate test and the sleep. A private lock would not be held across the sleep, and that window would be back. Calling it from interrupt context is safe on the same terms the timer handler already relies on -- acquire() disables interrupts, so a CPU holding tickslock cannot be interrupted into it. The e1000 signals on RXT0 (a frame or burst has landed) and RXDMT0 (the ring has fallen below its threshold, which is when waiting for the clock hurts most). Measured rather than asserted: /proc/netif reports wake_rx and wake_tick, and across three pings rx_frames and wake_rx both went 2 -> 6 -- every received frame woke the thread through the interrupt. wake_tick keeps advancing as the idle floor, which is what lwIP's timers need. socktest still passes and ping is still 0% loss. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2 |
||
| .. | ||
| boot.md | ||
| devices.md | ||
| filesystem.md | ||
| graphics.md | ||
| init.md | ||
| kernel.md | ||
| networking.md | ||
| README.md | ||
| schfs.md | ||
| syscalls.md | ||
| usb.md | ||
The system, layer by layer
What SchOS is today. Everything in this directory is built and running; what is merely intended lives in ../plan/.
The names, and what each one covers
uname -s reports SchIFT, the way every Unix reports its kernel rather than
its distribution.
| Layer | Name | What it is |
|---|---|---|
| System | SchOS | The distribution — kernel, userland, tooling |
| Kernel | SchIFT | Multi-core x86-64 kernel with a modular VFS |
| Filesystem | SchFS | Transactional, copy-on-write, the root filesystem |
| API | SchAPI | The native programming interface — designed, not built |
| Compositor | Schcom | Owns the display; v0 runs |
The stack, bottom to top
┌─────────────────────────────────────────────────┐
│ toybox mksh musl first-party cmd/ │ userland
├─────────────────────────────────────────────────┤
│ schinit — PID 1, job manifests, supervision │
├─────────────────────────────────────────────────┤
│ syscall table — Linux numbering, one .inc file │ ← the ABI seam
╞═════════════════════════════════════════════════╡
│ VFS │ sockets │ signals │ mmap │ poll │ procfs │
├──────┴─────────┴─────────┴──────┴──────┴────────┤
│ SchFS │ lwIP │ text/gfx │ buffer cache │
├─────────┴────────┴────────────┴─────────────────┤
│ device model — class vtables, bus binding │
├─────────────────────────────────────────────────┤
│ drivers: xHCI e1000 virtio-gpu VBE IDE PS/2│
├─────────────────────────────────────────────────┤
│ scheduler │ paging │ traps │ IRQ │ SMP │ DMA │ SchIFT core
└─────────────────────────────────────────────────┘
▲
UEFI loader (boot/uefi)
The two seams that matter are the syscall table and the device model. Above the first, software is ordinary and portable — musl and toybox are unmodified. Below the second, a driver never names its consumer and a consumer never names a driver.
Where it came from
SchOS began as xv6 and is now mostly something else. What survives from xv6 is the shape of the process table, the sleep/wakeup discipline, and the buffer cache. What has been replaced: the scheduler and trap path (rewritten for x86-64 and for more than one processor), the memory manager, the entire filesystem, the syscall layer, and every driver.
That inheritance is worth knowing when reading the code, because the parts that still look like xv6 follow xv6's conventions and the parts that do not, do not.
The documents
Read in this order if you are new:
| boot.md | Firmware to the first userspace process. The shortest path through the whole system. |
| kernel.md | Memory, processes, scheduling, traps, signals, SMP. |
| syscalls.md | The one table everything is generated from, and how a musl binary runs unmodified. |
| filesystem.md | The VFS, the buffer cache, mounts, procfs. |
| schfs.md | The copy-on-write root filesystem. |
| devices.md | Buses, classes, binding, and the vtables consumers talk to. |
| usb.md | xHCI, the USB core, and the three class drivers. |
| graphics.md | Framebuffer, text rendering, the console, and PSOGM. |
| networking.md | NIC drivers, lwIP, and both socket families. |
| init.md | schinit and the job manifests. |
Three rules that hold across all of it
The kernel and the host tools compile the same SchFS source. mkschfs
cannot disagree with the kernel about the on-disk format, because there is only
one implementation. Format bugs are found on the host, where a test takes a
second instead of a boot.
Syscalls are declared in exactly one place. kernel/sys/table.inc.
The constants, the dispatch table and the Linux translation map are all
generated from it, so a syscall cannot be half-registered.
A list you can read beats a list assembled by side effects. Drivers are
written out by hand in kernel/drivers/registry.c rather than collected by a
linker section, and platform devices are registered in one function rather than
inside each driver's init. The tradeoff is deliberate: self-registration is
nicer to write, and it means the list of what is in your kernel is not written
down anywhere you can read.