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

[Kent Gibson <warthog618@xxxxxxxxx>]

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