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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Wed, Jun 14, 2023 at 6:00 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> 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@xxxxxxxxx> 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.

You don't really need 100 LOC for a trivial request in C (it's a bit
over-dramatic :) ) but my thinking is: whether it's 5 lines or 10 or
100 - it doesn't change the fact that it is a fundamental change from
sysfs in that you need to write the code, compile it, link it against
the right libraries etc. etc. It will be so much more work no matter
how much you simplify the API and that is already enough to scare away
a lot of folks used to just writing to a bunch of files.

This is why I'm proposing the DBus API as a way of replacing several
features of sysfs that are so beloved by users: central authority over
GPIOs, easy to use from shell scripts (just replace "echo 223 >
export; echo output > 223/direction" etc. with "gdbus call --system
--dest io.gpiod1 --object-path /io/gpiod1/gpiochip2 --method
io.gpiod1.Chip.RequestLines <args>" which is just a tiny bit more
verbose but achieves the same goal and exposes all uAPI v2 features)
and only requires including the dbus daemon in your system which would
be packaged by most distros shipping libgpiod eventually. DBus has the
advantage of being usable from any language you fancy and still being
relatively fast.

In other words, I'm thinking that packing a lot of "helper" features
into libgpiod will only lead to feature creep but not achieve the goal
of pulling people away from sysfs.

Bart

> 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.