include: one folder per subsystem, and includes that name it

Sixty-five headers sat side by side in include/, so `#include "irq.h"`
said nothing about where irq.h was or what it belonged to, and errno.h,
stat.h and fcntl.h at the top shadowed the system's for any host tool
built with -I./include. They are in folders now -- arch/ core/ fs/
dev/ gfx/ net/ uapi/ (and ldls/ for the Linux driver layer) -- and
every include names the folder, as Linux's do: "core/proc.h".

Done mechanically and checked the hard way: the kernel built from this
tree disassembles identically to the one built from the tree before
it. The full image boots, and userland is the same set of programs.
Paths in docs and comments follow; docs/guides/layout.md has a table
of what is where, and tools/fix-includes.py rewrites old-style
includes from the folders in the tree, for code written before this.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
This commit is contained in:
Nexoniarz 2026-10-23 15:05:12 +02:00
commit a1c965da1e
267 changed files with 1560 additions and 1440 deletions

View file

@ -44,7 +44,7 @@ because there are none.** Everything the jump needs is computed before.
### The hand-off block
One page of low memory at `0x30000`, defined once in
[`include/schboot.h`](../../include/schboot.h) and included by both the loader
[`include/arch/schboot.h`](../../include/schboot.h) and included by both the loader
and `entry.S` so the two cannot disagree.
| Offset | What |
@ -463,7 +463,7 @@ what makes a loop over candidates legal at all.
| 6 | IDE 0 | usually the ESP, so usually not SchFS |
The **registered** devices are the ones found at probe time rather than known
at build time, numbered from 4 (`include/blkdev.h`): a SATA disk behind AHCI
at build time, numbered from 4 (`include/fs/blkdev.h`): a SATA disk behind AHCI
(`sata0`), an NVMe namespace (`nvme0n1`), each USB stick (`usb0`..`usb3`, the
first of them also seen as device 3), and every partition on any of them
(`sata0p2`, `nvme0n1p2`, `usb0p2`). When a disk registers, its GPT is read, or its MBR

View file

@ -11,7 +11,7 @@ Moving drivers out of the kernel entirely is [../plan/hybrid.md](../plan/hybrid.
## One list of everything attached
There is one list of everything attached, whatever bus found it:
`include/device.h` and `kernel/dev/device.c`, readable at `/proc/devices`.
`include/dev/device.h` and `kernel/dev/device.c`, readable at `/proc/devices`.
```
name bus class driver device

View file

@ -344,7 +344,7 @@ both need the `..` fixup and the ancestor-loop check that are not written.
A name is at most 255 bytes and a path 4096 including its NUL, Linux's
`NAME_MAX` and `PATH_MAX` (`VFS_NAME_MAX` and `VFS_PATH_MAX` in
`include/file.h`). Longer is `ENAMETOOLONG`. A filesystem may hold less: the v1
`include/fs/file.h`). Longer is `ENAMETOOLONG`. A filesystem may hold less: the v1
format stores `DIRSIZ` bytes and refuses longer names rather than matching on
their first 30.

View file

@ -265,7 +265,7 @@ is the mutual exclusion; the socket node never was.
## Text
[`include/text.h`](../../include/text.h) + `kernel/dev/text.c`.
[`include/gfx/text.h`](../../include/text.h) + `kernel/dev/text.c`.
**The font was never the problem — the character-cell grid was.** The console
draws text by indexing `font_data[256][16]` and stepping the cursor eight
@ -554,7 +554,7 @@ captured framebuffer.
## One palette
[`include/theme.h`](../../include/theme.h). There were three unrelated designs
[`include/gfx/theme.h`](../../include/theme.h). There were three unrelated designs
and the seams showed: the splash was deep purple with gold text deliberately
matching the *panic* screen, the console was cream with near-black text, and so
a healthy boot was dressed as a crash and then abruptly became an amber

View file

@ -61,7 +61,7 @@ one's bug.
### The protocol
`include/schinit.h`. **Every message is exactly one struct**, and PID 1 reads
`include/uapi/schinit.h`. **Every message is exactly one struct**, and PID 1 reads
`sizeof(struct)` or nothing: no length prefix to get wrong, no partial-message
state machine, and no allocation in the process that must not fail. The socket is
a `socketpair` inherited as fd 3.

View file

@ -108,7 +108,7 @@ one per-CPU block and everything that changes per CPU belongs in it.
> calls. But `%fs` here is per *CPU*, and a kernel thread changes CPU at every
> `sched()`. So the assumption is false for exactly the variables that most need
> to be right, and the failure is a null dereference deep in the scheduler on any
> machine with more than one core. `include/proc.h` carries the disassembly that
> machine with more than one core. `include/core/proc.h` carries the disassembly that
> proves it.
## Memory
@ -119,7 +119,7 @@ no buddy system, no zones, no page-frame database.
### Small objects
`kernel/core/kmem.c`, `include/kmem.h`. A slab is one page from `kalloc()` with
`kernel/core/kmem.c`, `include/core/kmem.h`. A slab is one page from `kalloc()` with
a header at the front and objects packed after it; free objects hold the free
list in their own first eight bytes.
@ -196,7 +196,7 @@ contiguous multi-page allocator, which is a separate thing and is not written.
## Processes
`struct proc` in [`include/proc.h`](../../include/proc.h). A fixed table of
`struct proc` in [`include/core/proc.h`](../../include/proc.h). A fixed table of
`NPROC` entries, allocated by linear scan.
**The field order at the top of the struct is fixed by assembly.** `trapasm.S`

View file

@ -334,7 +334,7 @@ format bugs are found on the host where a test takes a second instead of a boot.
## The source
```
include/schfs.h on-disk format + compile-time layout assertions
include/fs/schfs.h on-disk format + compile-time layout assertions
kernel/fs/schfs/btree.{c,h} the copy-on-write B-tree and its cursor
kernel/fs/schfs/schfs_int.h volume + object layer interface
kernel/fs/schfs/space.c allocation bitmap, derived from the tree at mount
@ -345,7 +345,7 @@ kernel/fs/schfs/kmount.c kernel: block device, mount slots, transaction brac
kernel/fs/schfs/vfs.c the fs_ops table: SchFS behind open/read/write
tools/mkschfs.c build an image from a directory tree
tools/schfs_fsck.c verify, list, extract
include/fsstat.h counters behind /proc/fsstat: where the time goes
include/fs/fsstat.h counters behind /proc/fsstat: where the time goes
tools/schfs_test.c B-tree torture harness
tools/schfs_objtest.c object layer: files, directories, space accounting
tools/posix/schfs_roundtrip.sh end-to-end filesystem test

View file

@ -20,7 +20,7 @@ hand-maintained:
| Generated | Where |
|---|---|
| The `SYS_*` constants | `include/syscall.h` |
| The `SYS_*` constants | `include/core/syscall.h` |
| The dispatch table | `kernel/sys/syscall.c` |
| The Linux translation map | `kernel/sys/linux_abi.c` |

View file

@ -55,7 +55,7 @@ Eight bytes:
| `pad` | to eight, so the grid indexes without a multiply |
`ch` was one byte holding a CP437 glyph, not a codepoint: the console mapped
UTF-8 down to CP437 on the way in, because that is what `include/font.h`
UTF-8 down to CP437 on the way in, because that is what `include/gfx/font.h`
contained. Widening it to the codepoint is what made Ą, Ę, Ś, Ω and the rest
possible, and no font change could have done it alone — a byte cannot *hold*
U+0104 whatever is drawing it. Mapping on the way in also meant the decision
@ -249,7 +249,7 @@ terminals behind your back. Right Alt is tracked as its own bit (`RALT`) for
the same reason; it used to share `ALT`, which is harmless for typing — neither
is used to look up a character — and wrong for chords.
`include/posix.h`'s `VTC_*` bits mirror `include/kbd.h`'s modifier bits, and a
`include/uapi/posix.h`'s `VTC_*` bits mirror `include/dev/kbd.h`'s modifier bits, and a
`_Static_assert` in `kbd.c` holds them together. A mismatch would be silent:
a chord set from userspace would simply never match, and the only symptom
would be a key that does nothing.

View file

@ -27,7 +27,7 @@ Linux's drivers are GPL-2.0-only and are not — see
## What the spec gives you for free
Everything in [`include/usb.h`](../../include/usb.h) comes from USB 2.0
Everything in [`include/dev/usb.h`](../../include/usb.h) comes from USB 2.0
chapter 9, which every device implements regardless of speed, class or vendor.
**That is what makes enumeration possible at all:** before you know anything