Thank you for sharing your thoughts!
Let me focus a bit on the case where the BSP kernel is lower than libc.
I.e., BSP layer comes with kernel 4.19 support for the machine in
question.
From your replies I see following options:
Option #1)
Use linux-libc-headers_5.4 as it is from poky. BSP layer provides the
lower version of kernel.
There may be selective bugs for application (Such as the libnl case
discussed on thread).
Deal with such applications case-by-case. By case-by-case, I mean, with
a linux-vendor-headers.
And make the application depend on linux-vendor-headers and look for the
header under custom path?
Option #2)
Implement a linux-libc-headers_4.19 (or the lower version you are at).
This way seemingly, the headers and kernel coming from BSP layer are
reconciled.
But, doing so violates the "Poky" distro, as "Poky" originally came with
linux-libc-headers_5.4 on Dunfell.
And, that is bad idea, hence create your own higher distro layer that
chooses linux-libc-headers_4.19.
All done, this approach still does not make things right!
As all testing/validation of 3rd-Party applications/3rd-Party layers
that Yocto Project
and different contributors have done using Poky and with the original
linux-libc-headers_5.4, are lost.
The lower version of headers are exposing those 3rd-Party
applications/3rd-Party to unknown issues.
It's sort of a dilemma!
The customer I am working with is worried about "Option #1"
(linux-libc-headers_5.4 + lower BSP kernel).
As discovery of 5.4 vs 4.19 bugs may not be easy to uncover. And then
for for a case-by-case fix they will
have to deviate away from linux-libc-headers, and make application
recipes, header path specific fixes.
"Option #2" (linux-libc-headers_4.19 from a higher distro layer), seems
like a way out, but at the cost of upending all
the testing and validation done with linux-libc-headers_5.4 for upstream
recipes/3rd-party layer.
Upgrading the machine from 4.19 to 5.4 is also off the table at this
time.
Option #3)
Selective Backport.
I am trying to get a feel if this is even the right path?
Let linux-libc-headers_5.4 be as it is from poky. BSP layer provides the
lower version of kernel.
Identify and freeze on list of the UAPI headers that customer plans to
use from linux-libc-headers_5.4.
Determine what is the gap between 4.19 and 5.4, backport those from 5.4
to 4.19.
Do a similar exercise with 3rd-party OSS applications/frameworks/layers
to be used on project and
weed out cases like libnl by way of backporting from 5.4 to 4.19.
Does this seem to keep things aligned with linux-libc-headers from
"Poky" and still addresses the holes that lower
BSP kernel creates when working with linux-libc-headers_5.4?
Thanks for your time!
--
Regards,
Sourabh
On 2021-04-23 23:31, Khem Raj wrote:
On 4/23/21 8:03 AM, Sourabh Banerjee wrote:
Hi All,
I need your suggestion on how to reconcile if the linux-libc-headers
and kernel versions are different?
For this discussion let's consider we are using the LTS branch YP-3.1
(Dunfell).
With Dunfell let's consider following 3 cases:
1) Machine is supported on 5.4 kernel
*Kernel Recipe:* linux-yocto_5.4.bb
*libc-headers:* meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb
There is no conflict in this case as libc-headers and linux-yocto
are on same version.
2) Machine is supported on a higher kernel (let's say 5.10)
*Kernel Recipe:* Let's assume provided by a BSP layer, linux_5.10.bb
*libc-headers:* meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb
The kernel version is higher in this case. But, should be okay as
5.10 UAPI is backward compatible and supports
linux-libc-headers_5.4 completely.
3) Machine is supported on a lower kernel (let's say 4.19)
Kernel Recipe: Let's assume provided by a BSP layer, linux_4.19.bb
libc-headers: meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.4.bb
The kernel version is lower in this case. I suppose, this may
lead to some runtime issues? As the kernel built from 4.19 will not be
able to support 5.4 UAPI fully.
What's the recommendation here? Should the BSP provider port
linux-libc-header_4.19.bb in BSP layer and
set PREFERRED_VERSION_linux-libc-headers = "4.19%"
I suspect this as UAPI headers such as following differ, and what
if this leads to runtime issues in case #3
- videodev2.h: This header is enhanced in 5.4
- fsverity.h : this header is not present in 4.19
right. all this combos should work fine in general case, however they
all are not tested with equal coverage. So best is always to try have
UAPIs older or equal to the kernel you intend to use. Generally
releases support supported LTS kernels and that should be good enough,
however if you have very old kernel and want to use latest yocto
release, be aware that we are not testing it with those old UAPIs so
all testing falls on your in this regard.
-- Regards,
Sourabh
--
Regards,
Sourabh
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150873):
https://lists.openembedded.org/g/openembedded-core/message/150873
Mute This Topic: https://lists.openembedded.org/mt/82312890/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
