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

[Bartosz Golaszewski <bgolaszewski@xxxxxxxxxxxx>]

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.

Bart