On 5/28/20 2:01 AM, Phil Blundell wrote:
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.
right, this is a quite common case in embedded Linux systems.
OLDEST_KERNEL is also useful for third party apps ( which are precompiled)
for peices of firmware that are compiled from source, this is less of a
problem, so using matching kernel headers has been a better approach,
given the number of such bugs.
p.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#138858):
https://lists.openembedded.org/g/openembedded-core/message/138858
Mute This Topic: https://lists.openembedded.org/mt/74502640/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
