Re: Confused as to what is going on with libgpiod v2

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Mon, Nov 22, 2021 at 11:47 PM Thomas Williams
<thomas.hugo.williams@xxxxxxxxx> wrote:
>
> Hi Bart,
>
> Thank you for responding.
>
> > > Sorry, horribly newbie questions and if I should be asking it
> > > somewhere else then please tell me.
> >
> > Hi Thomas! No, that's perfectly fine.
>
> That's good because I've been watching the traffic and it mostly seems
> to be reviews for code that is almost, but not quite, entirely unlike
> what I'm interested in. I'm guessing I'm either not looking hard
> enough or that it is for the kernel level implementations below the
> libgpiod API? - note that I've never had to deal with kernel level
> Linux development before, I'm an applications developer IRL.
>

The linux-gpio mailing list is mostly for kernel development but as
libgpiod lives closes to the kernel, it's developed here too.

> > > 1. Have there been any releases of libgpiod v2 ? I can't see any tags
> > > in the git repo later than v1.6.
> >
> > Nope, libgpiod v2 is under development and will probably still be so
> > for a while.
>
> OK.
>
> Could you explain what gives with something like this then:
> https://packages.debian.org/buster/libgpiod2 which advertises itself
> as "libgpiod2", but on closer inspection says version 1.2-3, which I
> assume is the corresponding version number here:
> https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
>
> Are libgpiod2 and libgpiod v2 referring to different meanings of "2" ?
>

Ha! Yes they do, it's distro's packaging shenanigans! Basically the
API version and the ABI version of libgpiod are different as we had a
non-compatible ABI change back during v0.x.y development. Current API
version for v1.6.x is 2.something.something. You'll see that while the
development files and other packages are just called libgpiod on
ubuntu and debian, the package containing the shared library is called
libgpiod2.

> > > 4. Should I even be trying to use libgpiod v2 yet ?
> >
> > Probably not, unless you have a good reason to (writing bindings or
> > whatever). It's not yet stable and is about to change again soon.
>
> LOL.
>
> Not sure what you mean by "bindings". A friend and I are porting

Language bindings are libraries in high-level languages that provide
an interface for low-level libraries. For instance: the libgpiod
python module exposes an interface in Python for using libgpiod's C
API.

> MMBasic, a *very* niche BASIC interpreter that is usually at home on
> microcontrollers, to Linux. The language has an array of inbuilt
> commands for controlling digital and analogue pins, SPI, I2C, etc. and
> libgpiod seems like the natural match for implementing the former.
>

I can't help you with that.

> A previous (Raspberry Pi specific) attempt by another developer
> floundered because (apocryphally) he was trying to treat the Pi as a
> microcontroller and programming to too low a level (directly to the
> Broadcom API) and finding that it was breaking on every O/S update. We
> were hoping to avoid a repeat of this by relying on a higher level
> API.
>

If you're using linux, then that's precisely the right approach.

> I imagine you are busy, but would you care to offer an opinion as to
> whether we should persevere with API v2 (where my friend has had some
> success) or roll-back to looking at v1.6.x, assuming that it even
> provides everything we need ?
>

v2 API is simply not stable. At the same time I'm working hard to
bring on the v2 release but I can't give you a timeline as I'm doing
it in my free (hahaha... :( ) time. For current development I'd
suggest sticking with v1.6 for now.

Bart

> Best wishes,
>
> Tom