On Mon, Jan 11, 2021 at 04:15:21PM +0100, Bartosz Golaszewski wrote:

On Mon, Jan 11, 2021 at 3:45 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Mon, Jan 11, 2021 at 03:06:28PM +0100, Bartosz Golaszewski wrote:

quoted

On Mon, Jan 11, 2021 at 2:45 PM Andy Shevchenko
[off-list ref] wrote:

quoted

On Mon, Jan 11, 2021 at 3:37 PM Bartosz Golaszewski [off-list ref] wrote:

quoted

From: Bartosz Golaszewski <redacted>

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.

quoted

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