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

[Kent Gibson <warthog618@gmail.com>]

On Thu, Dec 28, 2023 at 07:41:21PM -0600, Seamus de Mora wrote:
> On Thu, Dec 28, 2023 at 7:32 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > 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@gmail.com> 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.
>
> Kent,
>
> I am genuinely sorry if you took offense at my language. It truly
> wasn't intended to be offensive, yet you seem to "feel" that it was.
>

I call BS.  Refer to "just in case you can't be bothered" above.

> Given our inability to conduct communications that seem "civil" to
> both parties, I "FEEL" we should terminate this thread.
>

I'm happy to answer any relevant questions you have to ask.
But do stick to the point.

Cheers,
Kent.