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

[Kent Gibson <warthog618@xxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxx> 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.