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

[Andy Shevchenko <andy.shevchenko@gmail.com>]

On Mon, Jan 25, 2021 at 7:55 AM Kent Gibson <warthog618@gmail.com> wrote:
> 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@gmail.com> 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@gmail.com> wrote:
> > > > > On Mon, Jan 11, 2021 at 3:37 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > > >
> > > > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> > > > > >
> > > > > > 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.

Very good point!

> 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.

This reminds me of the Google vs. Oracle case where they pointed out
the header files (IIRC!).

> 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?

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



-- 
With Best Regards,
Andy Shevchenko