moving efi code to boot

docs/efi.md

@@ -10,7 +10,7 @@ that hands us a working CPU, a memory map, and a screen, and then gets out of th
 way.
 
 The key thing to understand: **UEFI is not our OS, it's a stepping stone.** It
-exists to load *us*. Our `src/efi.zig` is a UEFI *application* — a normal program
+exists to load *us*. Our `src/boot/efi.zig` is a UEFI *application* — a normal program
 that the firmware runs — and its entire purpose is to gather what the kernel needs
 and then jump into the kernel.
 
@@ -23,7 +23,7 @@ Partition (ESP)** and running a file at a well-known fallback path:
 esp/EFI/BOOT/BOOTX64.efi     <- the "removable media" default for x86-64
 ```
 
-That's exactly the layout `build.zig` assembles. It builds `src/efi.zig` for the
+That's exactly the layout `build.zig` assembles. It builds `src/boot/efi.zig` for the
 `uefi` target, installs it to `esp/EFI/BOOT/BOOTX64.efi`, and drops the kernel ELF
 at `esp/danos`. The `run-x86-64` step then points QEMU at OVMF (UEFI firmware for
 virtual machines) and presents that `esp/` directory to the guest as a FAT drive.
@@ -174,6 +174,6 @@ power on
 ```
 
 Bottom line: **UEFI's job is to give us a CPU, memory, and a framebuffer, then
-disappear.** `src/efi.zig` is the thin bridge that collects those gifts into a
+disappear.** `src/boot/efi.zig` is the thin bridge that collects those gifts into a
 `BootInfo`, tears down the firmware, and jumps into the kernel — after which we're
 on our own.