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:
parent
0e39e711f1
commit
a1c965da1e
267 changed files with 1560 additions and 1440 deletions
|
|
@ -25,7 +25,7 @@ hands over long mode already, and dropping back down to climb out again is a
|
|||
mode switch whose failure mode is a triple fault with no console. So entry.S
|
||||
publishes a 64-bit entry the same way it publishes the multiboot header: magic
|
||||
`SCH64BOO`, 8-byte aligned in the first 16 KB, then a 64-bit physical address.
|
||||
`include/schboot.h` owns the constants so loader and kernel cannot disagree —
|
||||
`include/arch/schboot.h` owns the constants so loader and kernel cannot disagree —
|
||||
the first attempt defined them twice and searched for `SCH6` while the
|
||||
assembler had written `6HCS`.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue