Slim Driver Gezginler _top_ 100%

¹Department of Computer Engineering, Boğaziçi University, Istanbul, Turkey ²Institute for Embedded Systems, Technical University of Munich, Germany ³Graduate School of Information Science, University of Tokyo, Japan ⁴School of Electrical Engineering, Universidad Nacional Autónoma de México, Mexico City, Mexico

The binary (≈ 4 KB) resides in ROM. Gezgin slim driver gezginler

A. Yılmaz¹, B. Klein², C. Sato³, D. Mendoza⁴ Klein², C

Slim‑Driver Gezginler : A Lightweight, Extensible Driver Framework for Heterogeneous Edge‑Computing Platforms Section 2 surveys related work

The contributions of this paper are:

The remainder of the paper is organized as follows. Section 2 surveys related work. Section 3 details the design goals and the SD‑G architecture. Section 4 formalizes the Gezgin lifecycle and presents verification results. Section 5 describes the implementation and experimental setup. Section 6 discusses performance and security outcomes. Section 7 outlines limitations and future work, and Section 8 concludes. | Approach | Core Idea | Strengths | Weaknesses | |----------|-----------|-----------|------------| | Linux driver model | Monolithic kernel modules with sysfs/driver core | Rich ecosystem, mature tooling | Large footprint (≈ 200 KB core+module), heavy initialization, complex dependency graph | | Zephyr | Microkernel + device driver model (static binding) | Small binary (≈ 30 KB), configurability via Kconfig | Requires compile‑time binding; limited runtime adaptability | | NuttX | POSIX‑like RTOS with modular drivers | POSIX compatibility, dynamic loading via ELF | Higher RAM usage (≈ 70 KB) and boot time due to full POSIX layer | | Fuchsia (Driver Host) | User‑space driver isolation, component framework | Strong isolation, sandboxing | Still in early adoption; overhead of user‑space context switches | | Micro‑Python hardware modules | Scripts as drivers | Extreme flexibility, easy prototyping | Performance limited by interpreter, not suitable for high‑throughput I/O | | Slim‑Driver Gezginler (this work) | Minimal core + dynamically discoverable plug‑ins (Gezgins) | Ultra‑low footprint, runtime composition, formal safety guarantees | Prototype stage, limited driver library (currently 12 drivers) |

| # | Contribution | |---|--------------| | | Definition of a core‑plus‑plug‑in architecture that isolates hardware abstraction from policy logic. | | C2 | Formal modeling of the Gezgin lifecycle (registration → negotiation → activation → retirement) and verification of dead‑lock freedom using TLA+ . | | C3 | Implementation of a prototype (≈ 12 KB core) for three hardware families, released under the permissive MIT license. | | C4 | Empirical evaluation of memory, latency, and throughput on real devices, compared against Linux‑based drivers and other lightweight frameworks (e.g., Zephyr, NuttX). | | C5 | Security analysis demonstrating reduced TCB size and fine‑grained capability confinement via a capability‑based access control (CBAC) model. |