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

[Kent Gibson <warthog618@xxxxxxxxx>]

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