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

[Seamus de Mora <seamusdemora@xxxxxxxxx>]

On Thu, Dec 28, 2023 at 7:32 PM Kent Gibson <warthog618@xxxxxxxxx> 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@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.

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.

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

Have a good day.

Rgds,
~S