Some thoughts following a brief test of libgpiod ver 2.1

[Seamus de Mora <seamusdemora@xxxxxxxxx>]

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

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.

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.

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?

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

Rgds,
~S