a1c965da1e
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
21 lines
936 B
C
21 lines
936 B
C
//
|
|
// assembler macros to create x86 segments
|
|
//
|
|
|
|
#define SEG_NULLASM \
|
|
.word 0, 0; \
|
|
.byte 0, 0, 0, 0
|
|
|
|
// The 0xC0 means the limit is in 4096-byte units
|
|
// and (for executable segments) 32-bit mode.
|
|
#define SEG_ASM(type,base,lim) \
|
|
.word (((lim) >> 12) & 0xffff), ((base) & 0xffff); \
|
|
.byte (((base) >> 16) & 0xff), (0x90 | (type)), \
|
|
(0xC0 | (((lim) >> 28) & 0xf)), (((base) >> 24) & 0xff)
|
|
|
|
#define STA_X 0x8 // Executable segment
|
|
#define STA_E 0x4 // Expand down (non-executable segments)
|
|
#define STA_C 0x4 // Conforming code segment (executable only)
|
|
#define STA_W 0x2 // Writeable (non-executable segments)
|
|
#define STA_R 0x2 // Readable (executable segments)
|
|
#define STA_A 0x1 // Accessed
|