Re: [libgpiod][RFC] helper functions for basic use cases

[Martin Hundebøll <martin@xxxxxxxxxx>]

On Mon, 2024-05-13 at 01:28 -0700, Bartosz Golaszewski wrote:
> > Anyway, have a think about it.
> > And I'll go take a look at the GLib bindings.
> > 
> 
> I have thought about it. I agree we could use some simpler
> interfaces. I don't
> agree their place is in core libgpiod. I understand we want to make
> this new
> interface seamless to use for end-users of libgpiod.
> 
> How about introducing a new header and a separate shared object:
> gpiod-ext.h
> and libgpiod-ext.so respectively? We could put all these new helpers
> in there,
> use the gpiod_ext_ prefix for all of them and distros could package
> the
> "extended" part of libgpiod together with the core library to avoid
> having to
> install multiple packages?
> 
> We'd keep the clear distinction between the low-level, core C library
> wrapping
> the kernel uAPI and the user-friendly C API. Though the user-friendly
> API in my
> book could be the GLib library but I understand not everyone wants to
> use GLib
> nor is familiar with GObject.

For our embedded use cases we would go far to avoid GLib in our root
filesystem (and our initrd too). This means relying on libgpiod only.

With the current core API, reading a single gpio line feels cumbersome.
Especially because we often use gpio labels to run the same binaries on
multiple hardware variants.

So we would really like to see an "extended" API, with wrappers to:
 * request a single gpio line from chip + offset
 * request a single gpio line from a (unique) label
 * read the current value of the requested gpio line
 * set the current value of the requested gpio line

Having those functionalities in a separate shared object is fine.

// Martin