The status of removing /sys/class/gpio and the global GPIO numberspace from the kernel
- Track: Embedded, Mobile and Automotive
- Room: H.1302 (Depage)
- Day: Saturday
- Start: 15:00
- End: 15:25
- Video only: h1302
- Chat: Join the conversation!
The GPIO sysfs interface for user space has been deprecated for many years. Its alternative, the GPIO character device and the associated libgpiod project, has been available since 2017. The library, along with its numerous bindings, has become the de facto standard tool for interacting with GPIOs from user space. Recently, it was supplemented by a D-Bus API and a reference implementation, addressing the long-standing issue of maintaining GPIO state persistence across different processes.
The sysfs interface is the primary user of the global GPIO number space in the kernel. Unlike other legacy components of the GPIO codebase, we cannot remove it without user space agreeing to stop using it. However, there remains a group of users who, for various reasons, refuse to migrate to the new uAPI. It has become evident that, without providing them with a 100% compatible experience, we will be stuck with the old interface indefinitely.
To address this, the latest addition to the family of user-space GPIO utilities is gpiod-sysfs-proxy[1] - a libfuse-based user-space compatibility layer for the GPIO sysfs interface under /sys/class/gpio, using libgpiod to talk to the kernel.
This talk will cover why we aim to remove /sys/class/gpio (along with the in-kernel legacy APIs), progress made so far, an introduction to gpiod-sysfs-proxy and the libgpiod D-Bus API, and a discussion of future plans.
[1] https://github.com/brgl/gpiod-sysfs-proxy
Speakers
Bartosz Golaszewski |