Future of Zephyr Device Model
summary
Zephyr now has a recently merged deferred device init that skips marked devices at boot and exposes an API to initialize them later, plus a prototype that encodes explicit before/after constraints per init function and runs a topological sort in a two‑step build to emit a linker ordering snippet. Experimental device state/events use zbus notifications to report init failures and deferred readiness, and there are ongoing questions about unloading drivers, power‑management interactions, and safe early‑boot callbacks.
AI-written summary · about
chapters (8)
- 0:00Zephyr device model intro
- 2:31Deferred init progress
- 4:40Lessons from implementation
- 5:03Near-term init priorities
- 14:14Device failure notifications
- 16:48Device unloading/reinit
- 20:02Q&A
- 40:58Closing remarks
related talks
23mA Dive into Zephyr Device Driver Model- 23mA Dive into Zephyr Device Driver Model
34mZephyr Project: RTOS Start-up and Initialization Flow
43mBeyond Static Devicetrees: Implementing Runtime Hardware Dynamism in Ze...- 34mZephyr Project: RTOS Start-up and Initialization Flow
30mZephyr ❤️ Internet: How Zephyr Speeds Implementation for New IoT Devices
31mA Zephyr User Story
33mZephyr Support for Heterogeneous SoCs