Re: [libgpiod][PATCH 6/6] core: add the kernel uapi header to the repository

[Kent Gibson <warthog618@xxxxxxxxx>]

On Mon, Jan 11, 2021 at 04:15:21PM +0100, Bartosz Golaszewski wrote:
> On Mon, Jan 11, 2021 at 3:45 PM Andy Shevchenko
> <andy.shevchenko@xxxxxxxxx> wrote:
> >
> > On Mon, Jan 11, 2021 at 03:06:28PM +0100, Bartosz Golaszewski wrote:
> > > On Mon, Jan 11, 2021 at 2:45 PM Andy Shevchenko
> > > <andy.shevchenko@xxxxxxxxx> wrote:
> > > >
> > > > On Mon, Jan 11, 2021 at 3:37 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> > > > >
> > > > > From: Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>
> > > > >
> > > > > In order to avoid any problems with symbols missing from the host linux
> > > > > kernel headers (for example: if current version of libgpiod supports
> > > > > features that were added recently to the kernel but the host headers are
> > > > > outdated and don't export required symbols) let's add the uapi header to
> > > > > the repository and include it instead of the one in /usr/include/linux.
> > > >
> > > > I doubt this is a good decision. First of all if the host (or rather
> > > > target, because host should not influence build of libgpiod) has
> > >
> > > I meant the host as in: the machine on which you build and which
> > > contains the headers for the target as well but I see what you mean.
> > >
> > > > outdated header it may be for a reason (it runs old kernel).
> > > > When you run new library on outdated kernel it might produce various
> > > > of interesting errors (in general, I haven't investigated libgpiod
> > > > case).
> > > > On top of that you make a copy'n'paste source code which is against
> > > > the Unix way.
> > > >
> > > > Sorry, but I'm in favour of dropping this one.
> > > >
> > >
> > > Cc: Thomas
> > >
> > > This problem has been raised by the buildroot people when we started
> > > requiring different versions of kernel headers to build v1.4 and v1.6.
> > > It turns out most projects simply package the uapi headers together
> > > with their sources (e.g. wpa_supplicant, libnl, iproute2) to avoid
> > > complicated dependencies. It's true that now the library can fail at
> > > runtime but I'm fine with that. Also: if we add new features between
> > > two kernel versions, we still allow to build the new library version
> > > except that these new features won't work on older kernels.
> >
> > I see.
> >
> > So known ways to solve this are
> >  - provide a header with source tree (see above)
> >  - modify code with ifdeffery against specific kernel versions
> >  - ...something else... ?
> >
> > Second item is what ALSA used (not sure if they provide a standalone driver
> > anymore). Ugly, but won't require header which may be staled.
> >
> > Any other solutions in mind?
> >
> 
> I tried to go the third way and just ignore the problem but I've
> received too many emails about that. :)
> 
> I don't like the ifdef hell so I prefer to bundle the header. I'm open
> to other suggestions, although I can't come up with anything else.
> 

Going off on a bit of a tangent, but I'm trying to add support for
decoding the GPIO ioctls into strace and am running up against a similar
issue.

The way strace does it is to check the uAPI header on the host and use
it if possible.  To handle where it may be stale, local types are
defined that mirror any types that may have been added since the header
was originally released.  If the corresponding type is available in the
linux header then it is used, else the local type.

This obviously creates a lot of pointless boilerplate code and
preprocessor chicanery so I floated the idea of just including the latest
header in the strace tree, as you are doing here for libgpiod.
But that raised the issue of licencing, specifically if you copy the
linux/gpio.h into a source tree does that mean that the whole project
becomes GPL 2.0?  That is an issue for strace as it is LGPL 2.1 - as is
libgpiod.

The Linux uAPI headers are under the GPL-2.0 WITH Linux-syscall-note,
which is also not totally clear on this point[1].

My gut feeling was that using and even copying API headers doesn't
constitute a derived work, as per the FSF view quoted in [1], and
ethically might even be less of a violation than copying and re-defining
individual types, but I'd rather not rely on a gut feeling.

Is there some clear opinion or precedent on this point?
i.e. are libgpiod and strace in legal licence jeopardy if they include
gpio.h in their source tree?

Cheers,
Kent.

[1] https://lkml.org/lkml/2020/2/21/2193