re-org docs

docs/file-system-development/danos-file-system-hierarchy-FSH.md

@@ -49,7 +49,7 @@ addressed by device id. `/dev` is the much smaller set of devices that have a dr
 willing to serve them, addressed by name.
 
 A device node is not a file the VFS can read. The bytes live in a driver process
-([drivers.md](../device-driver-development-guide/drivers.md)), so opening a `/dev` name has to resolve to that driver's
+([drivers.md](../device-driver-development/drivers.md)), so opening a `/dev` name has to resolve to that driver's
 IPC endpoint, and subsequent reads and writes are calls against it. Resolve-to-endpoint
 is exactly what the kernel's `fs_resolve` already does for any mounted backend, and
 `FileStatus.kind` is the field that marks a device node; **what is not implemented today
@@ -92,7 +92,7 @@ descriptor ring and left to read and write memory on its own. That ring is exact
 **`dma_alloc`** now provides — physically contiguous, pinned, uncacheable, with its
 physical address disclosed — and **`/lib/device/mmio`**'s barriers order the descriptor writes
 against the doorbell, and **`msi_bind`** delivers completions. So an AHCI or NVMe driver
-can be written today (the M14/M15 work in [driver-model.md](../device-driver-development-guide/driver-model.md); the earlier
+can be written today (the M14/M15 work in [driver-model.md](../device-driver-development/driver-model.md); the earlier
 "cannot host a block driver at all" is no longer true).
 
 What is *not* yet true is that it is safe. A device programmed with an arbitrary physical