Future of Zephyr Device Model
summary
Zephyr now has deferred device init merged so selected devices skip boot-time probing via linker-section trickery and are initialized later through a runtime API with no runtime overhead. A draft prototype uses a topological sort + linker-snippet build step (Python) that reads existing init entries plus Kconfig overrides to enforce before/after constraints; remaining problems include multiple compatibles and instance identification. A small proof-of-concept implements zbus notifications prototype for init failures and a basic unload/notify flow; it mostly works but needs review for kernel-dependency, listener costs, and power-management interactions.
AI-written summary · about
chapters (7)
- 0:00Zephyr device model future
- 1:04What is Zephyr device model
- 2:52Deferred device initialization
- 5:03Improving device initialization order
- 14:16Device failure notifications
- 32:13Dependencies and service models
- 40:42Q&A
related talks
15mLightning Talk: A Reusable Zbus Based Architecture, Abstracting Core Application Components
35mBoosting Product Development With the Zephyr RTOS – a Critical Reflection
15mIs the Zephyr Device Tree Too Complicated?
30mCombining Zephyr & C++20 to Build Safe, Low-footprint, Event-based Applicati...- 15mA Reusable Zbus Based Architecture, Abstracting Core Application...
16mKeynote: The Rise of Frameworks in Zephyr: From Devices to Subsystems to Frameworks
22mDynamic Modules Loading
27mInsights on the Re-Architecting to a Single Codebase, Running on Different Hardware...