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

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Wed, Jan 3, 2024 at 6:53 PM Seamus de Mora <seamusdemora@xxxxxxxxx> wrote:
>
> 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?

The driver is just a low-level interface between the core GPIO code
and the hardware. It does not typically take control of any GPIOs
(unless it calls gpiochip_request_own_desc() but that's an internal
detail).

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

It's exactly the same. The first user to claim a serial port (be it an
in-kernel serdev or a user opening /dev/ttyX) takes exclusive usage
and keeps the port until it releases it.

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

This is precisely what happens though (except for root being able to
override a regular user)? Or am I not understanding this paragraph?

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

I'm sorry, I'm not sure what *that model* is. Gpioset has no role in
persistence because it's merely a wrapper around libgpiod which is a
wrapper around the kernel uAPI which - by design - offers no
persistence.

FYI I understand the need for a user-space GPIO authority that's more
centralized and am working on a DBus daemon that will become exactly
that. However my cup runneth over so it'll be some time before it's
done. :(

Bartosz