Re: [libgpiod][PATCH 4/4] bindings: cxx: implement C++ bindings for libgpiod v2.0

[Kent Gibson <warthog618@gmail.com>]

On Mon, Jun 28, 2021 at 02:53:40PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 28, 2021 at 2:35 PM Kent Gibson <warthog618@gmail.com> wrote:
> > On Mon, Jun 28, 2021 at 02:30:05PM +0300, Andy Shevchenko wrote:
> > > On Sun, Jun 27, 2021 at 04:47:57PM +0800, Kent Gibson wrote:
> 
> ...
> 
> > > Kent, do I understand correctly that Go bindings use C library?
> >
> > No, the Go library is pure Go - it makes the ioctl calls itself.
> 
> Hmm... Interesting. Why is it so? Performance wise? Other points?
> 
> (It means you are basically replicating what libgpiod does, right?)
> 

Yeah, I ended up replicating libgpiod in Go.  Which actually came in
quite handy when it came to developing and testing the v2 uAPI - the
first support and test cases for that were written in Go.

A bit of history...
Initially I wrote a Go GPIO library for the Raspberry Pi for a
project that required better performance than was available via sysfs.
This pre-dated cdev/libgpiod availability on the Raspberry Pi.
That library manipulated the hardware directly via mapped memory, which
at the time was the only alternative to sysfs.  It is hideous and
horrible, but it works, and if you can live with the downsides it is also
quite performant.

Once cdev started being supported in Pi kernels I wanted to port the
library to that.  I did consider porting to libgpiod, but that had a few
downsides:

My original library was pure Go, which is trivial to cross-compile
for the Raspberry Pi (just call 'GOARCH=arm GOARM=6 go build' on my PC
and I have an executable that I can run on a Pi).
If you do call C libraries from Go and want to cross-compile then you
get sucked back into requiring the whole C cross-compilation toolchain.
Plus ease of deployment takes a hit - you now have to consider
the dependent libraries, not just the executable.
At that point you might as well just write in C.
Ease of cross-compilation and deployment was important to me (I'm
lazy), so this was a major factor.

Also, I had less trouble getting my head around the kernel uAPI than
I did the libgpiod API.  The uAPI was a smaller and simpler target,
and was accessible from Go, so I went directly to that.
(I think the libgpiod v2 API is much more approachable than v1, btw.)
Anyway, neither API at the time could implement my existing Go GPIO API,
so I ended up writing a new library instead - the one that replicates
the core functionality of libgpiod.
Ironically, I probably could implement that old API using the v2 uAPI...

So, in short, cos it was easier.

Cheers,
Kent.