On Fri, Apr 23, 2021 at 11:03 AM Sourabh Banerjee <sbane...@codeaurora.org> 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%" >
This is not something that we've really seen happen. When the libc-headers are property used, they'll check/probe for functionality and use what is available. If you have drivers/applications going directly at the libc-headers, versus the toolchain use. That is a different question. In this case, you'd be better of dealing with these on a per-application basis, and pointing them at alternate headers. You can dream up all sorts of issues, and most of them don't happen in practice. I've run hundreds of kernels that are older than the libc-headers, and have never run into an issue with standard, non-machine specific applications. Just look at master of oe-core. We continue to support 5.4, after I've bumped the headers to 5.10. Cheers, Bruce > 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 > > -- > Regards, > Sourabh > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#150857): https://lists.openembedded.org/g/openembedded-core/message/150857 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] -=-=-=-=-=-=-=-=-=-=-=-
