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

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

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?


-- 
With Best Regards,
Andy Shevchenko