Some thoughts following a brief test of libgpiod ver 2.1

Some thoughts following a brief test of libgpiod ver 2.1

[Seamus de Mora]

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

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

[Kent Gibson]

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

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

[Seamus de Mora]

On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> 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

Thanks for your response, Kent... but really - there's no need for a
supercilious remark like "hope you feel better soon"; you could
improve your communications if you'd drop remarks like that.

Anyway - I'm still wrestling with the "persistence" thing, but you've
made some good points.  The view is still a bit hazy, but perhaps I'm
seeing the "bigger picture" now? And I finally got around to reading
your post on SE; I made a comment & asked another Q.

One thing I'll comment on now is wrt the 'gpioget' tool, and the '-a'
option. If you want to create a tool, and call it 'gpioget' my feeling
is that a **read only** behavior should be the default. I'd recommend
you consider making that the case, and use the '-a' option to mean
"adjust"  :)

I'll follow up on the persistence business later, but just in case you
can't be bothered reading my comment to your SE post, let me re-state
the question I posed there:

I skimmed through your reference to the [GPIO chardev
uAPI](https://github.com/raspberrypi/linux/blob/rpi-6.1.y/include/uapi/linux/gpio.h).
I noted that there are several deprecated 'struct's in that API that
were part of ABI v1. QUESTION: Are these deprecated 'struct's used by
the `libgpiod v1.6.2/.3` - i.e. the libgpiod that is now current in
RPi bullseye (1.6.2) & bookworm (1.6.3)?

Rgds,
~S

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

[Kent Gibson]

On Thu, Dec 28, 2023 at 07:01:10PM -0600, Seamus de Mora wrote:
> On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Wed, Dec 27, 2023 at 07:19:54PM -0600, Seamus de Mora wrote:
> > > Hello,
>
> Thanks for your response, Kent... but really - there's no need for a
> supercilious remark like "hope you feel better soon"; you could
> improve your communications if you'd drop remarks like that.
>

I am well aware but sometimes you need to compromise and work with what
you've got, and given the mail I was responding to your comment is a bit
rich.
Happy to give it but not take it?

> Anyway - I'm still wrestling with the "persistence" thing, but you've
> made some good points.  The view is still a bit hazy, but perhaps I'm
> seeing the "bigger picture" now? And I finally got around to reading
> your post on SE; I made a comment & asked another Q.
>
> One thing I'll comment on now is wrt the 'gpioget' tool, and the '-a'
> option. If you want to create a tool, and call it 'gpioget' my feeling
> is that a **read only** behavior should be the default. I'd recommend
> you consider making that the case, and use the '-a' option to mean
> "adjust"  :)
>

That is your view, and I don't care about your feelings ;-).

If the line is already an input then it is a read-only operation.

Another view though is "I wanted to read the line as an input, so why
do I need to provide an option just to ensure it is configured
as an input?"

That was the default for v1 and there was no feedback requesting to
change it for v2.  And, depending on your views on API stability, that
means it can't be changed until libgpiod v3.

If that doesn't suit you, try an alias?

> I'll follow up on the persistence business later, but just in case you
> can't be bothered reading my comment to your SE post, let me re-state
> the question I posed there:
>

Perhaps improve your communication skills, or can't you be bothered??

> I skimmed through your reference to the [GPIO chardev
> uAPI](https://github.com/raspberrypi/linux/blob/rpi-6.1.y/include/uapi/linux/gpio.h).
> I noted that there are several deprecated 'struct's in that API that
> were part of ABI v1. QUESTION: Are these deprecated 'struct's used by
> the `libgpiod v1.6.2/.3` - i.e. the libgpiod that is now current in
> RPi bullseye (1.6.2) & bookworm (1.6.3)?
>

I've already responded there, but to reiterate, the deprecated v1
structs and uAPI remains until the transisition to v2 is complete.
If you are using the v1 uAPI then you are using those.
You can still use them for the time being, but new developments should
use v2 and existing v1 users should migrate to v2 at their earliest
convenience.

The kernel can be built with support for both in the meantime, though
v1 can also be compiled out if you are building a custom kernel and are
sure you don't need v1.  That will probably change to be the default
sometime next year.

Cheers,
Kent.

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

[Seamus de Mora]

On Thu, Dec 28, 2023 at 7:32 PM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Thu, Dec 28, 2023 at 07:01:10PM -0600, Seamus de Mora wrote:
> > On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > On Wed, Dec 27, 2023 at 07:19:54PM -0600, Seamus de Mora wrote:
> > > > Hello,
> >
> > Thanks for your response, Kent... but really - there's no need for a
> > supercilious remark like "hope you feel better soon"; you could
> > improve your communications if you'd drop remarks like that.
> >
>
> I am well aware but sometimes you need to compromise and work with what
> you've got, and given the mail I was responding to your comment is a bit
> rich.
> Happy to give it but not take it?
>
> > Anyway - I'm still wrestling with the "persistence" thing, but you've
> > made some good points.  The view is still a bit hazy, but perhaps I'm
> > seeing the "bigger picture" now? And I finally got around to reading
> > your post on SE; I made a comment & asked another Q.
> >
> > One thing I'll comment on now is wrt the 'gpioget' tool, and the '-a'
> > option. If you want to create a tool, and call it 'gpioget' my feeling
> > is that a **read only** behavior should be the default. I'd recommend
> > you consider making that the case, and use the '-a' option to mean
> > "adjust"  :)
> >
>
> That is your view, and I don't care about your feelings ;-).
>
> If the line is already an input then it is a read-only operation.
>
> Another view though is "I wanted to read the line as an input, so why
> do I need to provide an option just to ensure it is configured
> as an input?"
>
> That was the default for v1 and there was no feedback requesting to
> change it for v2.  And, depending on your views on API stability, that
> means it can't be changed until libgpiod v3.
>
> If that doesn't suit you, try an alias?
>
> > I'll follow up on the persistence business later, but just in case you
> > can't be bothered reading my comment to your SE post, let me re-state
> > the question I posed there:
> >
>
> Perhaps improve your communication skills, or can't you be bothered??
>
> > I skimmed through your reference to the [GPIO chardev
> > uAPI](https://github.com/raspberrypi/linux/blob/rpi-6.1.y/include/uapi/linux/gpio.h).
> > I noted that there are several deprecated 'struct's in that API that
> > were part of ABI v1. QUESTION: Are these deprecated 'struct's used by
> > the `libgpiod v1.6.2/.3` - i.e. the libgpiod that is now current in
> > RPi bullseye (1.6.2) & bookworm (1.6.3)?
> >
>
> I've already responded there, but to reiterate, the deprecated v1
> structs and uAPI remains until the transisition to v2 is complete.
> If you are using the v1 uAPI then you are using those.
> You can still use them for the time being, but new developments should
> use v2 and existing v1 users should migrate to v2 at their earliest
> convenience.
>
> The kernel can be built with support for both in the meantime, though
> v1 can also be compiled out if you are building a custom kernel and are
> sure you don't need v1.  That will probably change to be the default
> sometime next year.
>
> Cheers,
> Kent.

Kent,

I am genuinely sorry if you took offense at my language. It truly
wasn't intended to be offensive, yet you seem to "feel" that it was.

Given our inability to conduct communications that seem "civil" to
both parties, I "FEEL" we should terminate this thread.

Have a good day.

Rgds,
~S

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

[Kent Gibson]

On Thu, Dec 28, 2023 at 07:41:21PM -0600, Seamus de Mora wrote:
> On Thu, Dec 28, 2023 at 7:32 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Thu, Dec 28, 2023 at 07:01:10PM -0600, Seamus de Mora wrote:
> > > On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > On Wed, Dec 27, 2023 at 07:19:54PM -0600, Seamus de Mora wrote:
> > > > > Hello,
> > >
> > > Thanks for your response, Kent... but really - there's no need for a
> > > supercilious remark like "hope you feel better soon"; you could
> > > improve your communications if you'd drop remarks like that.
> > >
> >
> > I am well aware but sometimes you need to compromise and work with what
> > you've got, and given the mail I was responding to your comment is a bit
> > rich.
> > Happy to give it but not take it?
> >
> > > Anyway - I'm still wrestling with the "persistence" thing, but you've
> > > made some good points.  The view is still a bit hazy, but perhaps I'm
> > > seeing the "bigger picture" now? And I finally got around to reading
> > > your post on SE; I made a comment & asked another Q.
> > >
> > > One thing I'll comment on now is wrt the 'gpioget' tool, and the '-a'
> > > option. If you want to create a tool, and call it 'gpioget' my feeling
> > > is that a **read only** behavior should be the default. I'd recommend
> > > you consider making that the case, and use the '-a' option to mean
> > > "adjust"  :)
> > >
> >
> > That is your view, and I don't care about your feelings ;-).
> >
> > If the line is already an input then it is a read-only operation.
> >
> > Another view though is "I wanted to read the line as an input, so why
> > do I need to provide an option just to ensure it is configured
> > as an input?"
> >
> > That was the default for v1 and there was no feedback requesting to
> > change it for v2.  And, depending on your views on API stability, that
> > means it can't be changed until libgpiod v3.
> >
> > If that doesn't suit you, try an alias?
> >
> > > I'll follow up on the persistence business later, but just in case you
> > > can't be bothered reading my comment to your SE post, let me re-state
> > > the question I posed there:
> > >
> >
> > Perhaps improve your communication skills, or can't you be bothered??
> >
> > > I skimmed through your reference to the [GPIO chardev
> > > uAPI](https://github.com/raspberrypi/linux/blob/rpi-6.1.y/include/uapi/linux/gpio.h).
> > > I noted that there are several deprecated 'struct's in that API that
> > > were part of ABI v1. QUESTION: Are these deprecated 'struct's used by
> > > the `libgpiod v1.6.2/.3` - i.e. the libgpiod that is now current in
> > > RPi bullseye (1.6.2) & bookworm (1.6.3)?
> > >
> >
> > I've already responded there, but to reiterate, the deprecated v1
> > structs and uAPI remains until the transisition to v2 is complete.
> > If you are using the v1 uAPI then you are using those.
> > You can still use them for the time being, but new developments should
> > use v2 and existing v1 users should migrate to v2 at their earliest
> > convenience.
> >
> > The kernel can be built with support for both in the meantime, though
> > v1 can also be compiled out if you are building a custom kernel and are
> > sure you don't need v1.  That will probably change to be the default
> > sometime next year.
> >
> > Cheers,
> > Kent.
>
> Kent,
>
> I am genuinely sorry if you took offense at my language. It truly
> wasn't intended to be offensive, yet you seem to "feel" that it was.
>

I call BS.  Refer to "just in case you can't be bothered" above.

> Given our inability to conduct communications that seem "civil" to
> both parties, I "FEEL" we should terminate this thread.
>

I'm happy to answer any relevant questions you have to ask.
But do stick to the point.

Cheers,
Kent.

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

[Seamus de Mora]

On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> 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.
> > <snip>

> 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

Yes - the device driver on my bulleye is current; that change was
committed back in 1Q 2023 IIRC...

I hope I've not already asked this, but:
In ver 1.6.X of libgpiod, gpioset exits immediately, and returns to
the bash prompt. The GPIO line remains set at the value designated
after gpioset exits. AIUI, the driver change from 1Q 2023 was
responsible for this.

In ver 2.1 of libgpiod, gpioset (without options) does not exit. This
means there is no return to the bash prompt. The GPIO line still
remains set at the designated value, so there is no change in the
behavior of the GPIO line between ver 1.6.X and 2.1.

My question is why does the un-optioned gpioset ver 2.1 not exit - as
it did in ver 1.6.X?

Thanks,
~S

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

[Kent Gibson]

On Wed, Jan 03, 2024 at 01:51:53AM -0600, Seamus de Mora wrote:
> On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > 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.
> > > <snip>
>
> > 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
>
> Yes - the device driver on my bulleye is current; that change was
> committed back in 1Q 2023 IIRC...
>
> I hope I've not already asked this, but:
> In ver 1.6.X of libgpiod, gpioset exits immediately, and returns to
> the bash prompt. The GPIO line remains set at the value designated
> after gpioset exits. AIUI, the driver change from 1Q 2023 was
> responsible for this.
>
> In ver 2.1 of libgpiod, gpioset (without options) does not exit. This
> means there is no return to the bash prompt. The GPIO line still
> remains set at the designated value, so there is no change in the
> behavior of the GPIO line between ver 1.6.X and 2.1.
>
> My question is why does the un-optioned gpioset ver 2.1 not exit - as
> it did in ver 1.6.X?
>

You did, and I answered on SE.
But to reiterate; gpioset v1 exited immediately and that caused
confusion when the driver would revert the line to its default state.
That made it look like gpoioset wasn't doing anything or was generating
a glitch.
That results in "gpioset doesn't work" bug reports, and we got tired of
that.
The decision was to make it block by default to make it clearer that you
lose control over the line when it exits.

In short, we changed it because people complained about it, either
explicitly or implicitly.

The -t0 option can be used to emulate the v1 behaviour.

Cheers,
Kent.

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

[Seamus de Mora]

On Wed, Jan 3, 2024 at 3:49 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Wed, Jan 03, 2024 at 01:51:53AM -0600, Seamus de Mora wrote:
> > On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > 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.
> > > > <snip>
> >
> > > 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
> >
> > Yes - the device driver on my bulleye is current; that change was
> > committed back in 1Q 2023 IIRC...
> >
> > I hope I've not already asked this, but:
> > In ver 1.6.X of libgpiod, gpioset exits immediately, and returns to
> > the bash prompt. The GPIO line remains set at the value designated
> > after gpioset exits. AIUI, the driver change from 1Q 2023 was
> > responsible for this.
> >
> > In ver 2.1 of libgpiod, gpioset (without options) does not exit. This
> > means there is no return to the bash prompt. The GPIO line still
> > remains set at the designated value, so there is no change in the
> > behavior of the GPIO line between ver 1.6.X and 2.1.
> >
> > My question is why does the un-optioned gpioset ver 2.1 not exit - as
> > it did in ver 1.6.X?
> >
>
> You did, and I answered on SE.

I missed that - for me I guess it's lost in the details.

> But to reiterate; gpioset v1 exited immediately and that caused
> confusion when the driver would revert the line to its default state.
> That made it look like gpoioset wasn't doing anything or was generating
> a glitch.
> That results in "gpioset doesn't work" bug reports, and we got tired of
> that.
> The decision was to make it block by default to make it clearer that you
> lose control over the line when it exits.
>
> In short, we changed it because people complained about it, either
> explicitly or implicitly.
>
> The -t0 option can be used to emulate the v1 behaviour.

But... you've also explained that libgpiod/gpioset's
default/proper/correct behavior is to delegate the persistence issue
to the driver (or pinctrl in the RPi case) - right?

So it **sounds like** what you are saying is this:

    gpioset does *not exit* because people complained about lack of
    persistence. When the persistence issue was fixed in the driver,
    we also fixed it in gpioset by not allowing it to exit.

Have I got that right??

If so, why not stick by your initial assertion that persistence is a
driver issue - not a libgpiod issue?

I won't make a recommendation - or tell you what I *think/feel* -
because I know "you don't care", but if this is the case...

Best Rgds,
~S

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

[Kent Gibson]

On Wed, Jan 03, 2024 at 01:47:54PM -0600, Seamus de Mora wrote:
> On Wed, Jan 3, 2024 at 3:49 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Wed, Jan 03, 2024 at 01:51:53AM -0600, Seamus de Mora wrote:
> > > On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
>
> > But to reiterate; gpioset v1 exited immediately and that caused
> > confusion when the driver would revert the line to its default state.
> > That made it look like gpoioset wasn't doing anything or was generating
> > a glitch.
> > That results in "gpioset doesn't work" bug reports, and we got tired of
> > that.
> > The decision was to make it block by default to make it clearer that you
> > lose control over the line when it exits.
> >
> > In short, we changed it because people complained about it, either
> > explicitly or implicitly.
> >
> > The -t0 option can be used to emulate the v1 behaviour.
>
> But... you've also explained that libgpiod/gpioset's
> default/proper/correct behavior is to delegate the persistence issue
> to the driver (or pinctrl in the RPi case) - right?
>
> So it **sounds like** what you are saying is this:
>
>     gpioset does *not exit* because people complained about lack of
>     persistence. When the persistence issue was fixed in the driver,
>     we also fixed it in gpioset by not allowing it to exit.
>
> Have I got that right??
>
> If so, why not stick by your initial assertion that persistence is a
> driver issue - not a libgpiod issue?
>
> I won't make a recommendation - or tell you what I *think/feel* -
> because I know "you don't care", but if this is the case...
>

The behaviour was changed in A driver, and as noted by Stefan even that
is in the vendor tree, not the mainline tree.

Your perspective is too narrow - we need to deal with the general case.

Cheers,
Kent.

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

[Seamus de Mora]

On Wed, Jan 3, 2024 at 5:25 PM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Wed, Jan 03, 2024 at 01:47:54PM -0600, Seamus de Mora wrote:
> > On Wed, Jan 3, 2024 at 3:49 AM Kent Gibson <warthog618@gmail.com> wrote:
   [ snip ]
> >     gpioset does *not exit* because people complained about lack of
> >     persistence. When the persistence issue was fixed in the driver,
> >     we also fixed it in gpioset by not allowing it to exit.
> >
> > Have I got that right??
> >
> > If so, why not stick by your initial assertion that persistence is a
> > driver issue - not a libgpiod issue?
> >
> > I won't make a recommendation - or tell you what I *think/feel* -
> > because I know "you don't care", but if this is the case...
> >
>
> The behaviour was changed in A driver, and as noted by Stefan even that
> is in the vendor tree, not the mainline tree.
>
> Your perspective is too narrow - we need to deal with the general case.

Probably my perspective is rather narrow; as I said at the top of this
thread, "I have zero Linux kernel experience."

But I know that we need persistence, and it should be possible to get
that in a rational fashion. But not to worry, I'll try to find an
explanation for all of this  that makes sense to one with a narrow
perspective.

Best Rgds,
~S

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

[Stefan Wahren]

Hi,

> 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

in order to increase the confusion, i need to mention that this behavior only applies to the vendor kernel tree. The bcm2835 pinctrl driver in mainline kernel always falls back to GPIO input during the pin is freed since 2016.

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

[Bartosz Golaszewski]

On Thu, Dec 28, 2023 at 2:20 AM Seamus de Mora <seamusdemora@gmail.com> 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

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

[Seamus de Mora]

On Wed, Jan 3, 2024 at 4:47 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Thu, Dec 28, 2023 at 2:20 AM Seamus de Mora <seamusdemora@gmail.com> 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

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

[Bartosz Golaszewski]

On Wed, Jan 3, 2024 at 6:53 PM Seamus de Mora <seamusdemora@gmail.com> wrote:
>
> On Wed, Jan 3, 2024 at 4:47 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > On Thu, Dec 28, 2023 at 2:20 AM Seamus de Mora <seamusdemora@gmail.com> 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

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

[Seamus de Mora]

On Wed, Jan 3, 2024 at 12:35 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> On Wed, Jan 3, 2024 at 6:53 PM Seamus de Mora <seamusdemora@gmail.com> wrote:
> >
> > On Wed, Jan 3, 2024 at 4:47 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > >
> > > On Thu, Dec 28, 2023 at 2:20 AM Seamus de Mora <seamusdemora@gmail.com> wrote:
> > > >
> > >
        [ snip ]
> > >
> > 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).
>

OK - that *sounds* like a different story than the one your partner is
telling... do you guys ever "talk"?

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

OK - we agree on that much.

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

I think you and I have a common understanding on this point. I only
brought the root user in because the primary concern seems to be
"ownership" of the line, and I thought 'root' could arbitrate that.

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

Well - we're back to 'square one' it seems. There must be persistence
in GPIO control. It gets back to my example with the bedroom light.
Do you agree that persistence must exist in GPIO control?

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

So - does that mean that we're going to have to wait for version 3 (or
4?) of libgpiod to get something that provides persistence of GPIO
control?

I apologize if this sounds "short", but if we cannot agree that
persistence is fundamental to GPIO control, then I'm at a loss for
words.

Best Rgds,
~S

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

[Kent Gibson]

On Wed, Jan 03, 2024 at 04:09:01PM -0600, Seamus de Mora wrote:
> On Wed, Jan 3, 2024 at 12:35 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> >
> > On Wed, Jan 3, 2024 at 6:53 PM Seamus de Mora <seamusdemora@gmail.com> wrote:
> > >
> > > On Wed, Jan 3, 2024 at 4:47 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > >
> > > > On Thu, Dec 28, 2023 at 2:20 AM Seamus de Mora <seamusdemora@gmail.com> wrote:
> > > > >
> > > >
>         [ snip ]
> > > >
> > > 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).
> >
>
> OK - that *sounds* like a different story than the one your partner is
> telling... do you guys ever "talk"?
>

Formerly, once the user releases the line it becomes unowned.  That is
certainly true from the userspace perspective.  My interpretation is
that when a user releases the request the line ownership reverts to the
driver, cos in reality that is now in control of the line.

Sure we talk, but we can also have differing points of view.
You clearly have no problems talking, and I still take issue with
your tone.  Where is that damn hatchet?

> > >
> > > 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.
> >
>
> OK - we agree on that much.
>
> > >
> > > 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?
> >
>
> I think you and I have a common understanding on this point. I only
> brought the root user in because the primary concern seems to be
> "ownership" of the line, and I thought 'root' could arbitrate that.
>

Even root cannot access a line held by gpioset, at least not via the
GPIO uAPI.  Root would have to kill the process holding the line first.

> > >
> > > 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.
>
> Well - we're back to 'square one' it seems. There must be persistence
> in GPIO control. It gets back to my example with the bedroom light.
> Do you agree that persistence must exist in GPIO control?
>
> > 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. :(
> >
>
> So - does that mean that we're going to have to wait for version 3 (or
> 4?) of libgpiod to get something that provides persistence of GPIO
> control?
>

And there is that tone again...

No, AIUI this will be added to libgpiod or be a separate component.
No API changes involved and so no major version bump.

These things always take longer than you would like, and the gpioset
interactive mode is partly my attempt to provide an interrim solution
until the daemon is available.

> I apologize if this sounds "short", but if we cannot agree that
> persistence is fundamental to GPIO control, then I'm at a loss for
> words.
>

I would rather focus on providing a solution to your problem, whatever
that actually is, rather than arguing over whether the existing options
are sufficiently persistent, or what persistence even means in this
context.

The underlying issue is that the post-release behaviour is not clearly
defined across the GPIO driver interface. IIRC there has been some
discussion on signalling to the driver that it should not alter the line
post-release (on second thought maybe I'm thinking of the reading the
input/output buffer distinction), but if that were to go ahead it needs
to be done in a way that is backwardly compatible, all the way out to the
ABI, and involves updating ALL the drivers to suit.  All that is a
non-trivial task, i.e. you are looking at a butt ton of work.
It is therefore worthwhile to examine the alternatives.

So, what exactly is your problem and how does that that absolutely require
"persistence" to solve?

Cheers,
Kent.

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

[Seamus de Mora]

On Wed, Jan 3, 2024 at 6:15 PM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Wed, Jan 03, 2024 at 04:09:01PM -0600, Seamus de Mora wrote:
> > On Wed, Jan 3, 2024 at 12:35 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:

> > >      [ snip ]

> > OK - that *sounds* like a different story than the one your partner is
> > telling... do you guys ever "talk"?
> >
>
> Formerly, once the user releases the line it becomes unowned.  That is
> certainly true from the userspace perspective.  My interpretation is
> that when a user releases the request the line ownership reverts to the
> driver, cos in reality that is now in control of the line.
>
> Sure we talk, but we can also have differing points of view.
> You clearly have no problems talking, and I still take issue with
> your tone.  Where is that damn hatchet?
>

I understand that... Like you, I also live in the real world, and deal
with people that sometimes see things differently. No need to get
tetchy again.

> > > >
      [ snip ]

> > > 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.
> >
> > Well - we're back to 'square one' it seems. There must be persistence
> > in GPIO control. It gets back to my example with the bedroom light.
> > Do you agree that persistence must exist in GPIO control?
> >
> > > 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. :(
> > >
> >
> > So - does that mean that we're going to have to wait for version 3 (or
> > 4?) of libgpiod to get something that provides persistence of GPIO
> > control?
> >
>
> And there is that tone again...

That's a logical follow-up question to the statement. Perhaps with a
tinge of the frustration I feel over not understanding why this
problem keeps getting bigger - or more elusive.

>
> No, AIUI this will be added to libgpiod or be a separate component.
> No API changes involved and so no major version bump.
>
> These things always take longer than you would like, and the gpioset
> interactive mode is partly my attempt to provide an interrim solution
> until the daemon is available.
>

That's reassuring, but I have to say this: It's unclear to me if we
even see the bottom of the well yet.

> > I apologize if this sounds "short", but if we cannot agree that
> > persistence is fundamental to GPIO control, then I'm at a loss for
> > words.
> >
>
> I would rather focus on providing a solution to your problem, whatever
> that actually is, rather than arguing over whether the existing options
> are sufficiently persistent, or what persistence even means in this
> context.
>
> The underlying issue is that the post-release behaviour is not clearly
> defined across the GPIO driver interface. IIRC there has been some
> discussion on signalling to the driver that it should not alter the line
> post-release (on second thought maybe I'm thinking of the reading the
> input/output buffer distinction), but if that were to go ahead it needs
> to be done in a way that is backwardly compatible, all the way out to the
> ABI, and involves updating ALL the drivers to suit.  All that is a
> non-trivial task, i.e. you are looking at a butt ton of work.
> It is therefore worthwhile to examine the alternatives.
>
> So, what exactly is your problem and how does that that absolutely require
> "persistence" to solve?

Are you really asking why persistence is necessary?
Or are you asking why I'm not keen on the command line options needed
to get persistence?

If I need to answer the first question, I'd like for you to first
explain how you illuminate an LED without it (e.g. imagine a warning
light telling a driver he's lost pressure in the brake lines in his
car).

WRT the second Q, all I can really say is that I am pretty
simple-minded. I need/want tools that I understand - tools that
operate like all the other tools I use now - or have used in the past
(e.g. tools that don't refuse to exit after they've completed their
assigned task(s), and tools that don't have to be coaxed to 'do the
right thing' by adding "options"). Before libgpiod tools, I used a
tool called 'gpio' - a part of WiringPi. Perhaps you'd like to spend
30 minutes to check it out?... I feel it's the essence of simplicity,
and quite straightforward to use. It did many things that libgpiod
tools are not required to do. I liked this tool because it operated in
the fashion of all the other tools I use. In "my world", with tools
I've used previously, setting a GPIO to High to illuminate an LED is a
very trivial task - by that I mean in the overall context of a project
I work on, turning LEDs on is not something I've ever had to spend
much time thinking about. Yet here I am today - explaining to the
libgpiod s/w developer why persistence is important?!

Apologies to you both if I've said anything that was offensive, but
the more I talk with you about this - the more confused I get. I think
I'll give this libgpiod stuff a rest - maybe I'll have a revelation.
One final request: You've mentioned this "microAPI" (??) several
times. Is that a document?; if so, can I get a copy?

Rgds,
~S

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

[Kent Gibson]

On Wed, Jan 03, 2024 at 09:22:25PM -0600, Seamus de Mora wrote:
> On Wed, Jan 3, 2024 at 6:15 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Wed, Jan 03, 2024 at 04:09:01PM -0600, Seamus de Mora wrote:
> > > On Wed, Jan 3, 2024 at 12:35 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > > >      [ snip ]
> > >
> > > So - does that mean that we're going to have to wait for version 3 (or
> > > 4?) of libgpiod to get something that provides persistence of GPIO
> > > control?
> > >
> >
> > And there is that tone again...
>
> That's a logical follow-up question to the statement. Perhaps with a
> tinge of the frustration I feel over not understanding why this
> problem keeps getting bigger - or more elusive.
>

The tone is unhelpful, and you know it.  Yet you persist.
You could've just asked when that might be available.

You think I'm not tired of trying to explain the same thing to you over
and over and over again?  You've been told how things work, and why.
You've been told what is being changed in the future to better address
your use case.  But you aren't satisfied unless things work just the way
you want.

> >
> > No, AIUI this will be added to libgpiod or be a separate component.
> > No API changes involved and so no major version bump.
> >
> > These things always take longer than you would like, and the gpioset
> > interactive mode is partly my attempt to provide an interrim solution
> > until the daemon is available.
> >
>
> That's reassuring, but I have to say this: It's unclear to me if we
> even see the bottom of the well yet.
>

I don't see how this comment helpful in any way.

> > > I apologize if this sounds "short", but if we cannot agree that
> > > persistence is fundamental to GPIO control, then I'm at a loss for
> > > words.
> > >
> >
> > I would rather focus on providing a solution to your problem, whatever
> > that actually is, rather than arguing over whether the existing options
> > are sufficiently persistent, or what persistence even means in this
> > context.
> >
> > The underlying issue is that the post-release behaviour is not clearly
> > defined across the GPIO driver interface. IIRC there has been some
> > discussion on signalling to the driver that it should not alter the line
> > post-release (on second thought maybe I'm thinking of the reading the
> > input/output buffer distinction), but if that were to go ahead it needs
> > to be done in a way that is backwardly compatible, all the way out to the
> > ABI, and involves updating ALL the drivers to suit.  All that is a
> > non-trivial task, i.e. you are looking at a butt ton of work.
> > It is therefore worthwhile to examine the alternatives.
> >
> > So, what exactly is your problem and how does that that absolutely require
> > "persistence" to solve?
>
> Are you really asking why persistence is necessary?
> Or are you asking why I'm not keen on the command line options needed
> to get persistence?
>
> If I need to answer the first question, I'd like for you to first
> explain how you illuminate an LED without it (e.g. imagine a warning
> light telling a driver he's lost pressure in the brake lines in his
> car).
>

Sure, and, I would have a process managing that LED.

So where has your app that manages the car gone?
Doesn't that persist?  Or does it magically appear when the pressure
light needs to be lit and then flit off back into the ether?

Why do you insist on managing everything, including your car warning
lights, from shell?

> WRT the second Q, all I can really say is that I am pretty
> simple-minded. I need/want tools that I understand - tools that
> operate like all the other tools I use now - or have used in the past
> (e.g. tools that don't refuse to exit after they've completed their
> assigned task(s), and tools that don't have to be coaxed to 'do the
> right thing' by adding "options").

That is exactly the point - when gpioset exits its task is done - and
the line is then free to revert.  And that isn't what you want - you
want it to hold the line, so now it doesn't exit.

Having to use options to get tools to behave as you want is too hard?
WTF.  I mean really.  Seems to me you just want to vent, not actually
solve your problem.

> Before libgpiod tools, I used a
> tool called 'gpio' - a part of WiringPi. Perhaps you'd like to spend
> 30 minutes to check it out?...

It is Pi specific and has different contraints to work with.  It plays
with hardware directly, quite possibly in dangerous ways (it does nothing
to prevent contention that I am aware of), and due to the architecture
change does not work for the RPi5.

You could almost certainly write something to emulate it using libgpiod.
I haven't personally had any need, so haven't bothered, particular since
up until now wiringPi itself filled that niche.

> I feel it's the essence of simplicity,
> and quite straightforward to use. It did many things that libgpiod
> tools are not required to do. I liked this tool because it operated in
> the fashion of all the other tools I use. In "my world", with tools
> I've used previously, setting a GPIO to High to illuminate an LED is a
> very trivial task - by that I mean in the overall context of a project
> I work on, turning LEDs on is not something I've ever had to spend
> much time thinking about. Yet here I am today - explaining to the
> libgpiod s/w developer why persistence is important?!
>
> Apologies to you both if I've said anything that was offensive, but
> the more I talk with you about this - the more confused I get. I think
> I'll give this libgpiod stuff a rest - maybe I'll have a revelation.

Seems very unlikely at this point.  <-- gratuitous snide remark ;-)

> One final request: You've mentioned this "microAPI" (??) several
> times. Is that a document?; if so, can I get a copy?
>

It isn't microAPI, uAPI stands for userspace API. So its full name is
the GPIO Character Device Userspace API.  It is covered by gpio.h,
though that really only describes the structs, not the ioctls or how to
use them.

I'm endeavouring to write up a more detailed textual description
of the ioctls for the kernel documentation, but I keep getting distracted
with other things, particularly the kid in the backseat asking if we are
there yet.  I've already sunk too much time in this today.

Cheers,
Kent.