Hello, In embedded linux systems, GPIO monitoring for edge-events is common. For example, OpenBMC has several applications/packages that monitor GPIOs for an extended period of time. phosphor-gpio-monitor: 1. Starts a systemd service on GPIO events 2. Sets a dbus property based upon initial state and on GPIO events https://github.com/openbmc/phosphor-gpio-monitor x86-power-control: 1. Controls system power based on different button presses https://github.com/openbmc/x86-power-control However, there seems to be a lot of duplicate code between these applications related to monitoring in general that looks like it could be reduced. GPIO monitoring tends to have the following steps: 1. Configure/set up the GPIO line for monitoring 2. Read the initial value of GPIO line 3. Take action based upon initial value 4. Wait for event by monitoring fd 5. Take action on event, then continue monitoring or cleanup A function could internally complete the common steps regardless of what GPIO line is being monitored such as steps 1, 2, and 4. The other steps unique to the GPIO being monitored could be handled by callbacks. The gpiod_ctxless_event_monitor functions seemed to do this partially, but were removed along with the rest of the ctxless functions in commit 9b6e6d268671ef2dd00d9a9abe7ba43d14e7a84b (ctxless: drop all context-less interfaces). https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/commit/?id=9b6e6d268671ef2dd00d9a9abe7ba43d14e7a84b Would there be an issue with adding a higher level abstraction to simplify GPIO monitoring? Thanks, Kyle