Plan to Throw One Away Pitfalls of API Design for Low-level User-space Libraries & Kernel Interfaces
summary
libgpiod and the GPIO character device evolve because v1 locks in struct layouts and APIs that users later demand to extend; after four years a v2 branch adds padding to exposed structs and switches to opaque containers so frequent allocations stay fast. The project also fixes 32/64-bit and 64-to-32 compatibility by explicit padding, changes timestamps to support monotonic and real-time (and upcoming hardware), and redesigns the model so line info is a snapshot and requests operate on sets of lines, enabling a forward-compatible user-space API.
AI-written summary · about
chapters (8)
- 0:00Intro
- 1:56GPIO character device & libgpiod
- 3:24Types of compatibility
- 9:43Add reserved space to your exposed structures
- 10:53Make all data structures exposed in library headers opaque
- 17:02Lesson #3 Make sure your exposed structures work on 32 and 64-bit architectures
- 19:06Some surprising details can break the ABI
- 21:20Don't try to keep the user-space data model same as the one in the kernel
related talks
05mLightning Talk: Effective APIs in Practice in C++
42mInter Process Confusion - Navigating Zephyr's IPC APIs
27mInsights on the Re-Architecting to a Single Codebase, Running on Different Hardware...
32mArchitecting an IoT Product Line: Part 1 - Scoping
01h 06mHourglass Interfaces for C++ APIs
30mSIG API Machinery Deep Dive - App...
47mLinkage in the Third Millenium. Ideas, Innovations, Experiments and Prototypes for Fl...
26mAPI design is UI design