Use Cases
DULI matters wherever interrupt handlers belong to software components that are not trusted with kernel privileges, but whose deadlines are still hard.
Motion control and pulse-train output
A PLC, servo drive, or robot joint computes the next pulse interval inside an interrupt and toggles a pin. The control loop typically needs 20 kHz or more, and jitter translates directly into position error.
- Handler stays in the component's protection domain.
- DULI sustains close to 300 kHz with <5% jitter at 100 kHz while another process runs.
- At 10 kHz, jitter is below 0.5%, about 60× better than a kernel-forwarded handler.
This is the case that pushed the design: the handler is safety-critical, but it is supplied by the component and cannot be trusted as kernel code.
UAV and flight-control consolidation
A modern flight controller runs radio link, sensor fusion, attitude control, logging, and telemetry. The radio and control loops are hard real-time; the rest is best-effort. Consolidating them onto one core cuts cost and weight, but only if the real-time tasks do not inherit the kernel's latency.
Control loop
A user-level handler reacts to the IMU interrupt in 15 cycles, with its own PMP domain and a hardware budget. A runaway loop is terminated.
Link and logging
UART, telemetry, and a best-effort vision or logging task keep running. DULI's fast returns stop frequent interrupts from eroding their throughput.
Third-party modules
A networking or vision component with a remotely reachable attack surface can be isolated as a process — its handlers included.
Industrial communication + edge inference
A domain controller runs a Modbus-RTU stack that interrupts once per byte alongside an image-recognition workload. Kernel forwarding collapses the background throughput at high baud rates; the software fast path still loses more than half of it.
DULI keeps the real-time foreground at 2 Mbps and loses under 17% FPS at 1 Mbps with V5 (24% with V1). At the common 115.2 kbps the penalty is at most 5 FPS, roughly 10× smaller than kernel-mediated delivery.
This is also the "cloud-style consolidation" case inside a machine: a latency-sensitive tenant and a throughput-oriented tenant on one core, with hardware-enforced isolation between them.
Secure domain controllers
Automotive and medical systems increasingly integrate components from different suppliers. A fault or compromise in one component must not become a trampoline into the rest of the system.
DULI's contribution to that story is narrow but essential: the interrupt path is no longer the exception to the isolation model. If a component's handler reads outside its domain or overruns its budget, the hardware returns from it immediately; the kernel is not re-entered, and the rest of the system keeps its timing.
When DULI is not the answer
- A single, fully trusted application. Kernel-level handlers are already fast; DULI adds domain machinery you do not need.
- Only one process needs acceleration. SBI-style TrustZone solutions are simpler if a single trusted domain covers the use case.
- Average throughput is the goal. UINTR-style mechanisms are designed for that; DULI optimizes the worst case, and deliberately ignores tail-chaining and similar average-case tricks.
- Multi-core consolidation. Single-core only for now; multi-core routing is future work.
Adoption path
| Your core | Recommended | Outcome |
|---|---|---|
| RISC-V with TCM | V2 | 29 cycles, +27% core area, no new SRAM footprint |
| Fixed bus interface | V1 | 37 cycles, +23% area, drop-in |
| Latency above all else | V5 | 15 cycles measured, +66% area |
| Existing microkernel | any variant | +2% kernel source lines, same API |