nexoniarz/SchOS
nexoniarz/SchOS
Watch
1
0
Fork
You've already forked SchOS
 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

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

Browse source 
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
Download patch file Download diff file Expand all files Collapse all files

4
boot/README.md
View file

@ -39,7 +39,7 @@ a second loader is correct exactly when it satisfies it.
| Framebuffer | `VBE_INFO_ADDR` | address, pitch, width, height, depth |
| Verbose flag | `BOOT_VERBOSE_FLAG_ADDR` | set by the F8 menu |
The addresses are defined once, in `include/memlayout.h` and `include/schboot.h`.
The addresses are defined once, in `include/arch/memlayout.h` and `include/arch/schboot.h`.
The kernel does not care which firmware produced them.
## The entry point
@ -50,7 +50,7 @@ triple fault with no console, so the kernel publishes an entry that takes the
machine as it already is.
`kernel/arch/x86_64/entry.S` carries a `sch64_header` — magic `SCH64BOO`,
8-byte aligned within the first 16 KB, followed by a 64-bit physical address —
found by scanning. `include/schboot.h` holds the magic so loader and kernel
found by scanning. `include/arch/schboot.h` holds the magic so loader and kernel
cannot disagree.
The 32-bit multiboot entry is still in `entry.S` and now has no caller: the

6
boot/common/ui.c
View file

@ -10,9 +10,9 @@
*/
#include "ui.h"
#include "../../include/theme.h"
#include "../../include/font.h"
#include "../../include/logo.h"
#include "../../include/gfx/theme.h"
#include "../../include/gfx/font.h"
#include "../../include/gfx/logo.h"
/* "Draw the glyph, leave the background alone." Not a colour anyone can mean:
* the palette is 24-bit, so the high byte is free for a sentinel. */

6
boot/uefi/main.c
View file

@ -25,7 +25,7 @@
// computed before.
#include "efi.h"
#include "../../include/schboot.h"
#include "../../include/arch/schboot.h"
#include "../common/ui.h"
// Where the kernel expects to find things comes from schboot.h, included
@ -108,7 +108,7 @@ static int VERBOSE_BOOT;
// Remote debugging, off unless somebody picks it out of the boot menu -- and
// the entry that picks it only exists in a build made with DEBUG=1. See
// SCHBOOT_DEBUG_FLAG in include/schboot.h for why the consent is asked for at
// SCHBOOT_DEBUG_FLAG in include/arch/schboot.h for why the consent is asked for at
// this particular moment.
static int DEBUG_BOOT;
@ -395,7 +395,7 @@ open_kernel(EFI_HANDLE image)
// ---------------------------------------------------------------------------
// The console typeface
//
// See SCHBOOT_FONT_ADDR in include/schboot.h for why this is the loader's job
// See SCHBOOT_FONT_ADDR in include/arch/schboot.h for why this is the loader's job
// and not the kernel's. Everything here is best-effort: a machine with no
// console.ttf on its ESP boots with the font in the kernel image, which is
// the same font, and says nothing about it.