Re: [libgpiod] Some thoughts following a brief test of libgpiod ver 2.1

[Seamus de Mora <seamusdemora@xxxxxxxxx>]

On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
>
> On Wed, Dec 27, 2023 at 07:19:54PM -0600, Seamus de Mora wrote:
> > Hello,
> >
> > I've done some testing/evaluation of the 'libgpiod ver 2.1', and I'd
> > like to share a few thoughts from that experience. By way of
> > introduction, I have a degree in Electrical Engineering, and I like to
> > experiment and build things using "small computers" that run Linux. I
> > have zero Linux kernel experience. I did my testing on a Raspberry Pi
> > model 3 running a variant of Debian "bullseye".
> >
>
> Then you might want to update your kernel - the kernel device driver was
> changed to support peristing [1].
>
> I get this on my Pi4 running bookworm:
>
> $ gpioset -t0 GPIO23=0
> $ gpioinfo GPIO23
> gpiochip0 23    "GPIO23"                output
> $ gpioget -a GPIO23
> "GPIO23"=inactive
> $ gpioinfo GPIO23
> gpiochip0 23    "GPIO23"                output
> $ gpioset -t0 GPIO23=1
> $ gpioget -a GPIO23
> "GPIO23"=active
>
>
> I can confirm that the line values output match those reported by
> gpioget, so the gpioset is persisting.
>
> Btw, that device driver change should even be in recent Pi bullseye
> kernels too - I just happen to be running bookworm.
>
> > 1. I do not agree with the lack of "persistence" - at least as far as
> > it seems to be practiced in the 'gpioset' tool. When it comes to
> > "turning things ON and OFF", there is a long-established paradigm that
> > says when something is 'turned ON', it remains ON until the user takes
> > an action to turn it OFF. This seems simple and obvious to me. Using
> > the light switch in my bedroom as a simple example, I cannot see the
> > logic behind a Design Decision that requires me to keep my finger on
> > the light switch to keep it OFF so I can sleep.
> >
>
> The issue here is one of resource management and ownership.
> gpioset cannot guaranteed the state of the line after it returns as it
> no longer owns it - the ownership is contained in a file descriptor
> returned by the kernel, and a process' file descriptors are all closed
> automatically when a process exits.
> Ownership then returns to the device driver which may do what it sees
> fit with it.
>
> The gpioset documentation mentions that the line will return to its
> default state, which is typically and historically the case, but this
> is not strictly correct - it is up to the device driver what happens to
> the line.
> And, as demonstrated above, with the current Pi GPIO device driver the
> allows the line state to persist.
>
> I ramble about this more in my answer to a related question on
> StackExchange[2].
>
> > When I was in school we studied 'state machines'. I felt I had a
> > decent understanding of them - they were useful in designing automated
> > systems. Yet, in 'gpioset' it seems the concept of a 'state' has been
> > turned on its ear! We can 'set' a GPIO pin to a state, but that state
> > reverts immediately (a single clock cycle?). There seems to be an
> > underlying thought/theory at work in 'gpioset' that demands that it be
> > kept resident in memory to maintain a 'state'. There may be hardware
> > systems that demand continuous software oversight to function, but I
> > know of no such GPIO hardware systems. Also, AFAIK previous
> > programming interfaces/libraries all had "persistence".
> >
>
> > I'll make one final comment re. 'gpioset' wrt to the '-z / -daemonize'
> > option: First, this option seems to admit the failings of "lack of
> > persistence", but beyond that lies a question: How does one control
> > the daemon? The only way I could terminate the daemon was to search
> > for, and then kill the process. At least with '&`, one gets
> > notification of the process id.
> >
>
> The -z option is for a set and forget use case - the keep the finger
> on the button that you mentioned above.
>
> If that doesn't fit your use case then don't use the -z option?
>
> If you want a simple daemon then try a script line this:
>
> #!/bin/bash
> # Example of using the gpioset --interactive mode to create a simple GPIO daemon.
> #
> # Other programs can drive the GPIO by writing commands to the pipe,
> # e.g.
> #
> # echo toggle > /tmp/gpiosetd
> #
> # or
> #
> # echo "set GPIO23=1" > /tmp/gpiosetd
> #
> # similar to setting with the deprecated sysfs interface.
>
> pipe=/tmp/gpiosetd
> mkfifo $pipe
> trap "rm -f $pipe" EXIT
> # as bash will block until something is written to the pipe...
> echo "" > $pipe &
> gpioset -i GPIO23=0 < $pipe > /dev/null
>
>
> > 2. Why does a tool with 'get' in the name write/change GPIO
> > parameters? Would it not make more sense to relegate 'gpioget' to a
> > simply **reading** and reporting the state of the GPIO?
> >
>
> You want the -a/--as-is option.
> If you use that, and no other options, then the electrical configuration
> of the line will remain unchanged.
>
> That isn't the default, as historically the expected and desired behaviour
> is to switch the line to an input (which is always safe) and read the
> line.
>
> And the other options are there as you MAY want to change the
> electrical configuration.
>
> > I'll stop here. I don't really expect a considered reply because AIUI
> > this (libgpiod) project has been going on for 5 or 6 years now. I
> > assume that there have been other attempts to inject critical
> > thoughts, and they have clearly been dismissed. I felt that without
> > expressing my thoughts here I would fall in with the silent majority
> > whose enthusiasm and support for the present design is assumed... I
> > can't have that. :)
> >
>
> Cool, hope you feel better soon.
>
> Cheers,
> Kent.
>
> [1] https://github.com/raspberrypi/linux/commit/022689f0973d87956b2e5e8aaa0c29803cdb2a71
> [2] https://raspberrypi.stackexchange.com/questions/136479/confusion-with-libgpiod-and-the-gpiod-user-tools/143016#143016

Thanks for your response, Kent... but really - there's no need for a
supercilious remark like "hope you feel better soon"; you could
improve your communications if you'd drop remarks like that.

Anyway - I'm still wrestling with the "persistence" thing, but you've
made some good points.  The view is still a bit hazy, but perhaps I'm
seeing the "bigger picture" now? And I finally got around to reading
your post on SE; I made a comment & asked another Q.

One thing I'll comment on now is wrt the 'gpioget' tool, and the '-a'
option. If you want to create a tool, and call it 'gpioget' my feeling
is that a **read only** behavior should be the default. I'd recommend
you consider making that the case, and use the '-a' option to mean
"adjust"  :)

I'll follow up on the persistence business later, but just in case you
can't be bothered reading my comment to your SE post, let me re-state
the question I posed there:

I skimmed through your reference to the [GPIO chardev
uAPI](https://github.com/raspberrypi/linux/blob/rpi-6.1.y/include/uapi/linux/gpio.h).
I noted that there are several deprecated 'struct's in that API that
were part of ABI v1. QUESTION: Are these deprecated 'struct's used by
the `libgpiod v1.6.2/.3` - i.e. the libgpiod that is now current in
RPi bullseye (1.6.2) & bookworm (1.6.3)?

Rgds,
~S