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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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

[snip]

Bart





[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux