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

[Seamus de Mora <seamusdemora@xxxxxxxxx>]

On Wed, Jan 3, 2024 at 4:47 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
>
> On Thu, Dec 28, 2023 at 2:20 AM Seamus de Mora <seamusdemora@xxxxxxxxx> wrote:
> >
>
> [snip]
>
> >
> > 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.
> >
>
> This begs the question: WHO is the user? Are you making an assumption
> that the bash process (and its associated UID) that invoked gpioset is
> THE ONLY user on your multi user linux system? When gpioset acquires
> the GPIO for exclusive usage, it becomes THE user but as soon as it
> releases it - anyone else (with appropriate permissions) can come
> around and re-claim that GPIO.
>
I thought this issue of line ownership had been resolved...  i.e. the
system driver would take control of the line once the user's process
had exited? Maybe I'm confused on this point, but I *thought* I had
read that somewhere else?

Nevertheless, to address your questions: No - I didn't mean to infer
that there's only one user. I understand that you (library developer)
need to account for different users. But GPIO control is not a unique
issue in Linux (or any multi-user OS). It is the same if we were
talking about control of a serial port/UART... how is that arbitrated
between users?

WRT a GPIO line, I'd say "the user" is the one who issued the gpioset
command. In the context of your example ("When gpioset acquires the
GPIO for exclusive usage"), why could gpioset (or the user who issued
the gpioset command) not 'make a claim for exclusive usage' of the
GPIO line? If other users/processes subsequently attempted to claim
the same line, their claim would simply be disallowed - unless they
were `root`. Is there a reason why this model of ownership could not
work?
>
> To use your light switch example: you turn it ON and take a step back.
> The light is still on. But then your friend walks by and turns it OFF
> because you were not actively blocking access to that switch.
>

Granted, I did not take the issue of "light switch ownership" into
account in that example.

> > 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".
> >
>
> If you're referring to sysfs, then it has no more persistence than a
> driver that requests a GPIO and keeps it requested. You can imagine it
> as a central GPIO authority - a guy holding the lightswitch whom you
> tell how to set it. And your friend can tell him the opposite and
> he'll gladly comply.
>

No - not referring to sysfs... and I'm not sure I'm following your
argument here. But the only point I'm trying to make is wrt
'persistence': First, I'll assume that you are saying that gpioset has
a role to play in persistence, and that it does not delegate the
persistence question to the driver. Under that assumption, I am
suggesting that another model for persistence is as I outlined above.
And I'll ask again, "Is there a reason that model could not work?"

Best Rgds,
~S