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

[Kent Gibson <warthog618@xxxxxxxxx>]

On Wed, May 15, 2024 at 09:06:50AM +0200, Martin Hundebøll wrote:
> 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

That is in my proposal.

>  * request a single gpio line from a (unique) label

That one would require migrating a fair chunk of code from tools into
core.  Though that deals with multiple lines in parallel, whereas this
would only have to deal with a single line, so could just be a simple
interation to find the line.

Would a function that finds the (chip,offset) for a name be sufficient?

>  * read the current value of the requested gpio line
>  * set the current value of the requested gpio line

I did consider these, but didn't see a huge advantage over the existing.
gpiod_line_request_get_value(req, offset).  Too complicated?

OTOH, if you want to get the line by name then you don't know the offset
:(.

>
> Having those functionalities in a separate shared object is fine.
>

Good to know, but my intent is to make these ext functions still use
the core object so users can still use the existing core functions.

Cheers,
Kent.