RE: [libgpiod] Simplify GPIO monitoring

[Kyle Nieman <Kyle.Nieman@xxxxxxxxxx>]

> On Wed, Dec 13, 2023 at 5:50 PM Kyle Nieman <Kyle.Nieman@xxxxxxxxxx>
> wrote:
> >
> > 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=9
> > b6e6d268671ef2dd00d9a9abe7ba43d14e7a84b
> >
> > Would there be an issue with adding a higher level abstraction to
> > simplify GPIO monitoring?
> >
>
> I have decided for libgpiod v2 to remain as low-level and simple as possible
> and to only implement the bare minimum of functionality that at the same
> time covers all uAPI features.
>
> I'm working on DBus bindings for libgpiod v2 a part of which is a GLib
> abstraction layer that is a higher-level C interface. Could you give it a try and
> see if it works for your use-case?

Sorry for the delayed response.

The glib bindings look like they would work for what I had in mind. At least
based upon the example found in watch_line_value_glib.c.
https://github.com/brgl/libgpiod-private/blob/8db3f693494c18b643a50060e9126cb3e0fc6039/bindings/glib/examples/watch_line_value_glib.c#L85

>     https://github.com/brgl/libgpiod-private/tree/topic/dbus
>
> You can build it using --enable-bindings-glib with configure.
>
> If that's something useful, I could possibly release it separately from the
> DBus daemon.

I wouldn't worry about releasing glib bindings separately unless someone else
requests for it. The C++ bindings would work in my case but would be without
the loop abstraction provided by glib.

I was originally looking for an all-in-one abstraction for GPIO line value
watching that would cut down on the code. However, the more that I look at that
idea, the more issues I see with it due to it being specialized. Also, I didn't
realize how compact the line value monitoring was for C++ at least compared to
the C examples.

Thanks for your help,
Kyle
>
> Bart