Re: [libgpiod][PATCH 0/4] dedicated examples

[Kent Gibson <warthog618@gmail.com>]

On Wed, Jun 14, 2023 at 05:11:32PM +0200, Bartosz Golaszewski wrote:
> On Wed, Jun 14, 2023 at 3:57 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > Any functionality to add to libgpiod?
> >
> 
> I don't think so at the moment. Do you see anything obvious? I know,
> we spoke about putting the line resolver into libgpiod but I'm not
> sure we really want it. At least in the core library anyway. The GLib
> layer on top of libgpiod is a place that would be a good target for
> such a functionality IMO.
> 

Yeah, making the line resolver generally available is a can of worms.
Not prepared to take that one on at the moment.
I'm reasonably content to leave that to the user - as long as they can
readily iterate over the chips and lines themselves.
Maybe provide an iterator for all the lines in the system
available to the user?

> Other than that, I think libgpiod now has everything it needs to cover
> all use-cases for the uAPI.
> 

The point isn't that coverage is missing, it is to find ways to make
common tasks simpler.

The ones that spring to mind so far are:
 - C: requesting a single line as output
 - C: requesting a single line as input
 - providing a toggle function for line_value, as it is an enum which is
   a bit awkward.
 - the chip iterator in the python tools helpers.py
 - streaming operators for the enums where they are not automatically
   provided


The C ones are specifically for simple sysfs-like equivalence, as telling
users they need to replace a single write to a file with ~100 lines of C
is really hard to sell.
The config options would be as minimal as possible.
I was going to suggest the user could always reconfigure the line later
if they need extra features, but there is no function to return the
existing line config :-(.

Cheers,
Kent.