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

[Seamus de Mora <seamusdemora@xxxxxxxxx>]

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 ]

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