Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

["Phil Blundell" <pb@pbcl.net>]

On Wed, May 27, 2020 at 05:02:00PM -0700, Khem Raj wrote:
> https://github.com/torvalds/linux/commit/052876f8e5aec887d22c4d06e54aa5531ffcec75
> 
> this change e.g. in userspace checks for UINPUT_VERSION and decides to
> use one method
> or legacy to setup the device but this is really not gonna work with
> kernels where these ioctls
> are not available, it perhaps can be fixed to not check for
> UINPUT_VERSION but then there
> could be many such cases, how many can we chase.

There's nothing inherently incompatible about that kernel change.  The
compile-time UINPUT_VERSION tells you that things like struct uinput_setup
have been declared.  If you want to be compatible with both old and new
kernels at run time, the right way to do it is either to call
ioctl(UI_GET_VERSION) or just to handle the appropriate error returns
from the newly introduced ioctls.  It's entirely possible that there
is userspace code out there that's doing something silly with this,
but if there is then again I would take the view that it's just a bug
and ought to be fixed.

In terms of OE, the theory is that generated binaries ought to work with
any kernel of ${OLDEST_KERNEL} or newer.  Obviously, individual distros
are welcome to do whatever is tactically appropriate for them, that's
always fine.  If they know that they are only shipping a single kernel
version then it might be reasonable to compile against the matching
linux-libc-headers and set OLDEST_KERNEL to the same version in order
to minimise compatibility issues.  Of course, that then means they're
likely to be building against a different linux-libc-headers to
everyone else and that might introduce a different set of problems,
but it's a reasonable tradeoff to consider.

p.