igpu: WIP

docs/README.md

@@ -55,7 +55,9 @@ rather than restate it. Roughly in the order things happen at runtime:
 15. **[drivers.md](device-driver-development/drivers.md) — writing a driver.** The payoff: a driver is an
     ordinary ring-3 process that claims a device, maps its registers, and **sleeps
     until its hardware interrupts it**. The claim is the capability; `irq_ack` is the
-    unmask.
+    unmask. The condensed version: the
+    [new-driver checklist](device-driver-development/new-driver-checklist.md) —
+    the minimum steps from boot-log line to mapped registers.
 16. **[driver-model.md](device-driver-development/driver-model.md) — buses, classes and host controllers.** How
     real driver stacks factor into three shapes and how families share code. The
     three primitives it proposed are long since built (M13 capability passing,

docs/device-driver-development/drivers.md

@@ -4,7 +4,9 @@ In a monolithic kernel a driver is a function call away from everything: it runs
 ring 0, dereferences any physical address, and its interrupt handler *is* the ISR. In
 danos a driver is **an ordinary ring-3 process**. It has its own address space, it
 can crash without taking the kernel with it, and — the point of this document — it
-can be restarted ([resilience](../os-development/resilience.md)).
+can be restarted ([resilience](../os-development/resilience.md)). This document is
+the reasoning; the condensed do-this-then-that version is the
+[new-driver checklist](new-driver-checklist.md).
 
 That leaves three questions the kernel has to answer, because a process can't answer
 them for itself: