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

[andy.shevchenko@gmail.com]

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.

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

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