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

[Kent Gibson <warthog618@xxxxxxxxx>]

On Thu, Dec 28, 2023 at 07:01:10PM -0600, Seamus de Mora wrote:
> On Thu, Dec 28, 2023 at 3:29 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> >
> > On Wed, Dec 27, 2023 at 07:19:54PM -0600, Seamus de Mora wrote:
> > > Hello,
>
> Thanks for your response, Kent... but really - there's no need for a
> supercilious remark like "hope you feel better soon"; you could
> improve your communications if you'd drop remarks like that.
>

I am well aware but sometimes you need to compromise and work with what
you've got, and given the mail I was responding to your comment is a bit
rich.
Happy to give it but not take it?

> Anyway - I'm still wrestling with the "persistence" thing, but you've
> made some good points.  The view is still a bit hazy, but perhaps I'm
> seeing the "bigger picture" now? And I finally got around to reading
> your post on SE; I made a comment & asked another Q.
>
> One thing I'll comment on now is wrt the 'gpioget' tool, and the '-a'
> option. If you want to create a tool, and call it 'gpioget' my feeling
> is that a **read only** behavior should be the default. I'd recommend
> you consider making that the case, and use the '-a' option to mean
> "adjust"  :)
>

That is your view, and I don't care about your feelings ;-).

If the line is already an input then it is a read-only operation.

Another view though is "I wanted to read the line as an input, so why
do I need to provide an option just to ensure it is configured
as an input?"

That was the default for v1 and there was no feedback requesting to
change it for v2.  And, depending on your views on API stability, that
means it can't be changed until libgpiod v3.

If that doesn't suit you, try an alias?

> I'll follow up on the persistence business later, but just in case you
> can't be bothered reading my comment to your SE post, let me re-state
> the question I posed there:
>

Perhaps improve your communication skills, or can't you be bothered??

> I skimmed through your reference to the [GPIO chardev
> uAPI](https://github.com/raspberrypi/linux/blob/rpi-6.1.y/include/uapi/linux/gpio.h).
> I noted that there are several deprecated 'struct's in that API that
> were part of ABI v1. QUESTION: Are these deprecated 'struct's used by
> the `libgpiod v1.6.2/.3` - i.e. the libgpiod that is now current in
> RPi bullseye (1.6.2) & bookworm (1.6.3)?
>

I've already responded there, but to reiterate, the deprecated v1
structs and uAPI remains until the transisition to v2 is complete.
If you are using the v1 uAPI then you are using those.
You can still use them for the time being, but new developments should
use v2 and existing v1 users should migrate to v2 at their earliest
convenience.

The kernel can be built with support for both in the meantime, though
v1 can also be compiled out if you are building a custom kernel and are
sure you don't need v1.  That will probably change to be the default
sometime next year.

Cheers,
Kent.