Re: linux-libc-headers - how to handle for older kernels?


Mike Looijmans
 

On 02-12-19 10:19, Mikko.Rapeli@bmw.de wrote:
Hi,

On Mon, Dec 02, 2019 at 09:13:47AM +0000, Mike Looijmans wrote:
On 01-12-19 22:57, Peter Bergin via Lists.Yoctoproject.Org wrote:
Hi,

I'm currently working in a project using Yocto 2.6 (thud) release. It has
default kernel v4.18 and also linux-libc-headers from kernel v4.18. In my
project we will use kernel v4.1. I would like advice how to handle the
linux-libc-headers package for my project, should I use the v4.18 headers or
should I use the v4.1 header files which matches the running kernel?

From https://www.kernel.org/doc/html/latest/kbuild/headers_install.html:
"Kernel headers are backwards compatible, but not forwards compatible. This
means that a program built against a C library using older kernel headers
should run on a newer kernel (although it may not have access to new
features), but a program built against newer kernel headers may not work on an
older kernel."

With the information from the quote above I would directly use v4.1 headers as
my linux-libc-headers. But then reading the information in the file
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc makes me think
another round. It states:

"
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
...
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
"

The first part states that I should not change linux-libc-headers. But when I
read the last part I'm not sure about the interpretation and it could be for
my case. Just a matter of definition if v4.1 is extremely old compared to v4.18.

Then another thing comes in to the equation; the LIBC ABI. When I look into
the configuration of the glibc package it uses the configure switch
"--enable-kernel=3.2" which means it shall be compatible with all kernel newer
than v3.2. Then probably glibc is fine if it is compiled with v4.18 and run on
v4.1?

If building all applications against v4.18 headers but run on v4.1 kernel. I
have a feeling that there potentially can be problems here.

Please help me with some information about this and share your opinions? Are
there any risks at all to use v4.1 as linux-libc-headers in my Yocto build?
The only drawback I see is that it will be a new configuration not well tested
by the community. Are there other risks or drawbacks using your own version of
linux-libc-headers?

It is not broken, so please don't fix it.

OpenPLi has been using kernels way older than 4.1 with the kernel-headers
generated by OE/yocto and did not experience any problems with that. There's
about 50+ machines in there that have pre-built binary drivers that only work
with a particular kernel config and hence the old stuff.

There are some corner-cases with exotic kernels and exotic exports and exotic
boot executables that use the kernel compiler, but I doubt that you're in there...

If you have a kernel that exports something that's not in the regular headers,
it's way better to solve that using a syscall than trying to poke in low level
libc stuff.

So again, if you don't experience problems, please don't try to fix it...
How to find a Linux kernel uapi header file with custom ioctl() etc definitions which
are missing form the default linux-libc-headers?

Other recipes and SDK builds need these.

Copying the needed header files into the recipes who needs them is not ok.
One solution I can think of is to put the header into it's own
recipe/repository and then refer to it like any other library would. Refer to
that recipe from the module (or kernel) recipe that needs it. This way you
have your header in a single maintainable location and dependencies properly
taken care of.

If that's not something you could live with, share your recipes, since vague
problem descriptions will only get you vague solutions...

Join yocto@lists.yoctoproject.org to automatically receive all group messages.