Writing a driver

A driver in DurgX is a normal limited program. It never gets blanket hardware access. It gets exactly the capabilities for the device it manages.

What a driver is given

The Device Manager, a trusted but unprivileged program, finds your hardware once at boot, then hands each driver only its own capabilities.

The shape of a driver

fn driver_main(caps: DriverCaps) -> ! {
    let regs  = map_device_memory(caps.mmio);   // SYS_VM_MAP
    let ring  = attach_ring(caps.client_ring);  // requests from clients

    loop {
        // 1. Sleep until the device raises its interrupt.
        irq_wait(caps.irq);                     // behaves like a message wait

        // 2. Acknowledge the device and collect finished work.
        let done = regs.take_completions();

        // 3. Post results to the clients' completion queue.
        for c in done { ring.complete(c.user_data, c.result); }

        // 4. Start any new requests that arrived.
        while let Some(req) = ring.next_request() { regs.start(req); }
    }
}

Design it to be restarted

• Be idempotent. After a restart, the same request may be replayed. Doing it twice must be safe.
• Keep state outside. Queues of unfinished work should live where a fresh copy of the driver can pick them up.
• Reset the device cleanly at the start, so a half-finished operation does not confuse it.
• Never assume you are the first run. Check the device state, then continue.

What the supervisor receives when you crash

The supervisor can then restart you, switch you off or escalate. See Crashes and recovery.