Slim Driver Gezginler __top__ -

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

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

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) | Sato³, D

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