Re: [ANNOUNCE] libgpiod v2.0-rc3 released

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Fri, Feb 24, 2023 at 1:28 PM <andy.shevchenko@xxxxxxxxx> wrote:
>
> Thu, Feb 23, 2023 at 08:25:02PM +0100, Bartosz Golaszewski kirjoitti:
> > I decided to introduce a late change to the C++ bindings - mark all
> > public types as final since they already don't have virtual
> > destructors and inheriting from them makes little sense anyway. This
> > has little impact on the programming interface but I still think it's
> > worth another RC and I also have a gut feeling that makes me want to
> > sit down over the weekend and inspect the entire API once more before
> > carving it in stone for the foreseeable future.
> >
> > The tarball and git tree are in their usual places[1][2].
>
> Thank you for the update!
>
> A bit of an offtopic here (but related a bit as well), but since all parties
> are in Cc list I dare to ask.
>
> I have got one bug report internally and, while thinking over it (it has nothing
> to do with the library, but with the flow on how we change line states during
> requests and releases), realised that we probably have no knob to tell GPIO driver
> to which state pin should be left after release.
>

As Linus said - this does sound like the "safe-state" mechanism that
tends to be discussed on this list every three years or so. :)

> This at least allows several things to achieve:
> 1) emulation of the sysfs behaviour (to some extent) without a necessity of
>    the context (yes, I know that this is still error prone, but why not);

But this doesn't emulate anything. The released line is up for grabs
by either another user-space or a kernel user. It may have reverted to
the previous state on release but what happens next is anyone's guess.
IMO: It's simply wrong to rely on a state of non-requested line.

> 2) allow the possibility to grab a GPIO line and set it to the particular
>    state and leave the process off (makes sense in some setups where it's
>    guaranted that no other process will touch the line);

It may be right for some use-cases but it's ultimately *logically*
wrong. Even sysfs DOES actually request lines that are exported, ie
there IS a defined user who is driving the line. In this case there's
nobody responsible. And in order to read back the state you'd have to
request it anyway.

> 3) something else I forgot or not even thinking of.
>
> That said, would be nice to have an additional flag (during request?)
> to tell kernel what it should do with the line after releasing the
> handle from user space.
>

I agree on the in-kernel mechanism for defining some safe-state to
which a line would revert whenever unused but I would argue that
allowing user-space to specify such a state would be just inviting
people to doing even worse stuff than with sysfs.

Bart

> Thoughts?
>
> P.S. Sorry if I missed any discussion related to this in the past.
> In such case, please share the links.
>
> > [1] https://mirrors.edge.kernel.org/pub/software/libs/libgpiod/
> > [2] git://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git
>
> --
> With Best Regards,
> Andy Shevchenko
>
>