On Fri, Apr 23, 2021 at 12:06 PM Yi Fan Yu <yifan...@windriver.com> wrote: > > On 4/23/21 11:35 AM, Bruce Ashfield wrote: > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > 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. > > > maybe unrelated and anecdotal: > > I looked at a windriver bug related to a test in libnl called `test-genl` > > The failure only occurred in 5.4.X kernel. > and I was able to narrow it down to the 5.10 header update oe-core > causing the failure. >
libnl is known for this. It's basically the ioctl of the networking world. So that's consistent with what I said, it is rare, and is usually in tightly coupled applications. When that happens, we almost always just carry a header or two along with the application itself. Bruce > (if you are interested in details, talk to randy...) > > > 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 > > > > > > > > > > -- - 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 (#150860): https://lists.openembedded.org/g/openembedded-core/message/150860 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] -=-=-=-=-=-=-=-=-=-=-=-
