moving kernel code to kernel/

docs/testing.md

@@ -17,7 +17,7 @@ There are two layers:
 
 The framebuffer console draws pixels, which a test can't read without
 screen-scraping. So the kernel also writes everything to a **serial port**
-(`src/arch/x86_64/serial.zig`, a 16550 UART on COM1). `Console.write` mirrors every
+(`src/kernel/arch/x86_64/serial.zig`, a 16550 UART on COM1). `Console.write` mirrors every
 byte to it, so all kernel output — boot log, memory summary, exception reports —
 appears on serial as plain text.
 
@@ -29,7 +29,7 @@ a new architecture's UART is what makes the same tests run there.
 ## In-kernel test cases
 
 Building with `-Dtest-case=<name>` makes the kernel, after normal bring-up, run one
-self-test from `src/tests.zig` instead of idling. Each case writes structured
+self-test from `src/kernel/tests.zig` instead of idling. Each case writes structured
 markers to serial:
 
 ```
@@ -108,7 +108,7 @@ firmware, boot method, serial device). The cases are architecture-neutral —
 So bringing up a second architecture — an AArch64 Raspberry Pi is the motivating
 one — means:
 
-1. implement `src/arch/aarch64/` (CPU ops, its UART, exception vectors, page
+1. implement `src/kernel/arch/aarch64/` (CPU ops, its UART, exception vectors, page
    tables) behind the same `arch` interface,
 2. add an `aarch64` entry to `ARCHES` with its `qemu-system-aarch64` invocation,
 
@@ -118,7 +118,7 @@ architectures".
 
 ## Writing a new case
 
-1. Add a function to `src/tests.zig` and dispatch it in `run` on its name.
+1. Add a function to `src/kernel/tests.zig` and dispatch it in `run` on its name.
 2. Emit `[PASS]/[FAIL]` lines and a `DANOS-TEST-RESULT:` line (non-faulting cases),
    or trigger the condition and rely on the handler's output (faulting cases).
 3. Add an entry to `CASES` in `test/qemu_test.py` with the regex that proves it.