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

@ -5,22 +5,22 @@
// library, and the text console -- and only the first is a driver. The other
// two are now kernel/dev/gfx.c and do not name any driver at all, so the crash
// screen and the console draw on whatever hardware is bound rather than on
// this one by name. See include/gfx.h.
// this one by name. See include/gfx/gfx.h.
//
// What stays here is everything that knows *where the pixels are*: the mode the
// loader programmed and handed over in the boot block, the aperture it lives
// in, and the display class vtable that presents all of it as one of possibly
// several displays.
#include "types.h"
#include "x86.h"
#include "memlayout.h"
#include "defs.h"
#include "device.h"
#include "display.h"
#include "gfx.h"
#include "dma.h"
#include "schboot.h" /* the hand-off block */
#include "core/types.h"
#include "arch/x86.h"
#include "arch/memlayout.h"
#include "core/defs.h"
#include "dev/device.h"
#include "gfx/display.h"
#include "gfx/gfx.h"
#include "core/dma.h"
#include "arch/schboot.h" /* the hand-off block */
static volatile uchar *fb;
// Physical base of the linear framebuffer, as reported by VBE. Everything that
@ -115,7 +115,7 @@ vga_fb_init(uint64 phys_addr)
// --- display class implementation ------------------------------------------
//
// See include/display.h. The VBE framebuffer presenting itself as a generic
// See include/gfx/display.h. The VBE framebuffer presenting itself as a generic
// display, so a compositor is written against the class rather than against
// this file.

View file

@ -17,16 +17,16 @@
// shown up first on hardware where the guess was wrong, and until now there
// was nothing in the kernel capable of noticing it.
#include "types.h"
#include "defs.h"
#include "param.h"
#include "x86.h"
#include "spinlock.h"
#include "sleeplock.h"
#include "fs.h"
#include "file.h"
#include "pci.h"
#include "display.h"
#include "core/types.h"
#include "core/defs.h"
#include "core/param.h"
#include "arch/x86.h"
#include "core/spinlock.h"
#include "core/sleeplock.h"
#include "fs/fs.h"
#include "fs/file.h"
#include "dev/pci.h"
#include "gfx/display.h"
// The framebuffer lives in the first memory BAR big enough to hold a screen.
// Display controllers commonly expose two apertures -- the framebuffer and a