* [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing @ 2020-05-27 15:50 Khem Raj 2020-05-27 15:59 ` [OE-core] " Denys Dmytriyenko 2020-05-27 21:20 ` Richard Purdie 0 siblings, 2 replies; 25+ messages in thread From: Khem Raj @ 2020-05-27 15:50 UTC (permalink / raw) To: openembedded-core; +Cc: Khem Raj asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) this helps in using common header across multiple versions of kernel going back Signed-off-by: Khem Raj <raj.khem@gmail.com> --- .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc index 4481aa430c..933a01ba81 100644 --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc @@ -81,8 +81,11 @@ do_install_append_armeb () { } do_install_armmultilib () { - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h asm/bpf_perf_event.h + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h asm/swab.h asm/types.h asm/unistd.h + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then + oe_multilib_header asm/bpf_perf_event.h + fi } BBCLASSEXTEND = "nativesdk" -- 2.26.2 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 15:50 [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing Khem Raj @ 2020-05-27 15:59 ` Denys Dmytriyenko 2020-05-27 20:45 ` Khem Raj 2020-05-27 21:25 ` Richard Purdie 2020-05-27 21:20 ` Richard Purdie 1 sibling, 2 replies; 25+ messages in thread From: Denys Dmytriyenko @ 2020-05-27 15:59 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > this helps in using common header across multiple versions of kernel > going back This check should have been there from the beginning and for every header file. It's big PITA to sync this list up, especially when dealing with different glibc or kernel than OE-Core, e.g. external toolchains, etc. Any objections to making this check more generic for every entry in the list? -- Denys > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > index 4481aa430c..933a01ba81 100644 > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > @@ -81,8 +81,11 @@ do_install_append_armeb () { > } > > do_install_armmultilib () { > - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h asm/bpf_perf_event.h > + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h > oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h asm/swab.h asm/types.h asm/unistd.h > + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then > + oe_multilib_header asm/bpf_perf_event.h > + fi > } > > BBCLASSEXTEND = "nativesdk" > -- > 2.26.2 > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 15:59 ` [OE-core] " Denys Dmytriyenko @ 2020-05-27 20:45 ` Khem Raj 2020-05-27 20:56 ` Andre McCurdy 2020-05-27 21:25 ` Richard Purdie 1 sibling, 1 reply; 25+ messages in thread From: Khem Raj @ 2020-05-27 20:45 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: Patches and discussions about the oe-core layer On Wed, May 27, 2020 at 9:00 AM Denys Dmytriyenko <denis@denix.org> wrote: > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > > this helps in using common header across multiple versions of kernel > > going back > > This check should have been there from the beginning and for every header > file. It's big PITA to sync this list up, especially when dealing with > different glibc or kernel than OE-Core, e.g. external toolchains, etc. > > Any objections to making this check more generic for every entry in the list? > I thought about that, but then realized, there is a check for missing headers in the oe_multilib_header function which catches errors nicely so if we do this check before calling that function perhaps is going to subvert the error message which could be useful, since the aftereffect of the missing header can be a cryptic build error in applications, therefore went for limited edition. > -- > Denys > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > --- > > .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > > index 4481aa430c..933a01ba81 100644 > > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > > @@ -81,8 +81,11 @@ do_install_append_armeb () { > > } > > > > do_install_armmultilib () { > > - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h asm/bpf_perf_event.h > > + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h > > oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h asm/swab.h asm/types.h asm/unistd.h > > + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then > > + oe_multilib_header asm/bpf_perf_event.h > > + fi > > } > > > > BBCLASSEXTEND = "nativesdk" > > -- > > 2.26.2 > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 20:45 ` Khem Raj @ 2020-05-27 20:56 ` Andre McCurdy 0 siblings, 0 replies; 25+ messages in thread From: Andre McCurdy @ 2020-05-27 20:56 UTC (permalink / raw) To: Khem Raj Cc: Denys Dmytriyenko, Patches and discussions about the oe-core layer On Wed, May 27, 2020 at 1:45 PM Khem Raj <raj.khem@gmail.com> wrote: > > On Wed, May 27, 2020 at 9:00 AM Denys Dmytriyenko <denis@denix.org> wrote: > > > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > > > this helps in using common header across multiple versions of kernel > > > going back > > > > This check should have been there from the beginning and for every header > > file. It's big PITA to sync this list up, especially when dealing with > > different glibc or kernel than OE-Core, e.g. external toolchains, etc. > > > > Any objections to making this check more generic for every entry in the list? > > > > I thought about that, but then realized, there is a check for missing > headers in the oe_multilib_header function which catches errors nicely > so if we do this check before calling that function perhaps is going > to subvert the error message which could be useful, since the > aftereffect of > the missing header can be a cryptic build error in applications, > therefore went for limited edition. Just as another point of reference, I'm using kernel 3.12.x and both asm/perf_regs.h and asm/bpf_perf_event.h are missing. My solution was to downgrade bberror -> bbwarn in multilib_header.bbclass > > Denys > > > > > > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > > > --- > > > .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 ++++- > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > > > index 4481aa430c..933a01ba81 100644 > > > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > > > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > > > @@ -81,8 +81,11 @@ do_install_append_armeb () { > > > } > > > > > > do_install_armmultilib () { > > > - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h asm/bpf_perf_event.h > > > + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h > > > oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h asm/swab.h asm/types.h asm/unistd.h > > > + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then > > > + oe_multilib_header asm/bpf_perf_event.h > > > + fi > > > } > > > > > > BBCLASSEXTEND = "nativesdk" > > > -- > > > 2.26.2 > > > > > > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 15:59 ` [OE-core] " Denys Dmytriyenko 2020-05-27 20:45 ` Khem Raj @ 2020-05-27 21:25 ` Richard Purdie 2020-05-27 21:46 ` Khem Raj 2020-05-27 23:11 ` Denys Dmytriyenko 1 sibling, 2 replies; 25+ messages in thread From: Richard Purdie @ 2020-05-27 21:25 UTC (permalink / raw) To: Denys Dmytriyenko, Khem Raj; +Cc: openembedded-core On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > > this helps in using common header across multiple versions of > > kernel > > going back > > This check should have been there from the beginning and for every > header > file. It's big PITA to sync this list up, especially when dealing > with > different glibc or kernel than OE-Core, e.g. external toolchains, > etc. > > Any objections to making this check more generic for every entry in > the list? Yes, a strong objection. We don't want to support or encourage every kernel version out there. I also don't understand why people need to change the libc-headers anyway :( Cheers, Richard ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 21:25 ` Richard Purdie @ 2020-05-27 21:46 ` Khem Raj 2020-05-27 21:50 ` Richard Purdie 2020-05-27 21:52 ` Phil Blundell 2020-05-27 23:11 ` Denys Dmytriyenko 1 sibling, 2 replies; 25+ messages in thread From: Khem Raj @ 2020-05-27 21:46 UTC (permalink / raw) To: Richard Purdie Cc: Denys Dmytriyenko, Patches and discussions about the oe-core layer On Wed, May 27, 2020 at 2:25 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > > > this helps in using common header across multiple versions of > > > kernel > > > going back > > > > This check should have been there from the beginning and for every > > header > > file. It's big PITA to sync this list up, especially when dealing > > with > > different glibc or kernel than OE-Core, e.g. external toolchains, > > etc. > > > > Any objections to making this check more generic for every entry in > > the list? > > Yes, a strong objection. We don't want to support or encourage every > kernel version out there. > > I also don't understand why people need to change the libc-headers > anyway :( building products doesn't mean you are on the latest kernels sadly, that's just the reality of world and building userspace against way newer kernel-headers with older kernel underneath has unintended consequences. So its always better to use matching UAPIs to the kernel version to avoid these mismatches > > Cheers, > > Richard > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 21:46 ` Khem Raj @ 2020-05-27 21:50 ` Richard Purdie 2020-05-27 21:52 ` Phil Blundell 1 sibling, 0 replies; 25+ messages in thread From: Richard Purdie @ 2020-05-27 21:50 UTC (permalink / raw) To: Khem Raj Cc: Denys Dmytriyenko, Patches and discussions about the oe-core layer On Wed, 2020-05-27 at 14:46 -0700, Khem Raj wrote: > On Wed, May 27, 2020 at 2:25 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 > > > > ) > > > > this helps in using common header across multiple versions of > > > > kernel > > > > going back > > > > > > This check should have been there from the beginning and for > > > every > > > header > > > file. It's big PITA to sync this list up, especially when dealing > > > with > > > different glibc or kernel than OE-Core, e.g. external toolchains, > > > etc. > > > > > > Any objections to making this check more generic for every entry > > > in > > > the list? > > > > Yes, a strong objection. We don't want to support or encourage > > every > > kernel version out there. > > > > I also don't understand why people need to change the libc-headers > > anyway :( > > building products doesn't mean you are on the latest kernels sadly, > that's just the reality of world > and building userspace against way newer kernel-headers with older > kernel underneath has unintended consequences. Its not supposed to have any consequences, the kernel UAPI is supposed to be backwards compatible. Have you examples where things were broken? > So its always better to use matching UAPIs to the kernel > version to avoid these mismatches This should not be necessary and its actually really bad it it means a totally different userspace for every target :( Cheers, Richard ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 21:46 ` Khem Raj 2020-05-27 21:50 ` Richard Purdie @ 2020-05-27 21:52 ` Phil Blundell 2020-05-27 22:42 ` Andre McCurdy 1 sibling, 1 reply; 25+ messages in thread From: Phil Blundell @ 2020-05-27 21:52 UTC (permalink / raw) To: Khem Raj Cc: Richard Purdie, Denys Dmytriyenko, Patches and discussions about the oe-core layer On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > and building userspace against way newer kernel-headers with older > kernel underneath has unintended > consequences. Can you be more specific? If this doesn't work, it's just a bug and should be fixed. What problems are you having? p. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 21:52 ` Phil Blundell @ 2020-05-27 22:42 ` Andre McCurdy 2020-05-27 22:57 ` Khem Raj 0 siblings, 1 reply; 25+ messages in thread From: Andre McCurdy @ 2020-05-27 22:42 UTC (permalink / raw) To: Phil Blundell Cc: Khem Raj, Richard Purdie, Denys Dmytriyenko, Patches and discussions about the oe-core layer On Wed, May 27, 2020 at 2:52 PM Phil Blundell via lists.openembedded.org <pb=pbcl.net@lists.openembedded.org> wrote: > > On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > > and building userspace against way newer kernel-headers with older > > kernel underneath has unintended > > consequences. > > Can you be more specific? If this doesn't work, it's just a bug and > should be fixed. What problems are you having? I don't have an up to date example, but I've been using kernel version specific libc headers for all my projects for many years. The issue which prompted me to do that was run time crashes from libcap-ng and the historical commit message was: ---- linux-libc-headers: use 3.3.8 kernel header files for mips platforms If libcap-ng is unable to probe kernel capabilities at runtime then it will assume the kernel supports all features defined by the libc kernel headers. Since our default libc kernel headers (linux 3.14) define capabilities which are not available in linux 3.3 based stblinux kernel used for our MIPS platforms, that causes runtime crashes. As a workaround, force an older version of linux-libc-headers for all MIPS platforms to try to remove that discrepancy between the kernel's capabilities and those defined in the libc kernel headers. ---- The risk of using bleeding edge linux-libc-headers with an older kernel may be low, it's not zero. Since OE testing doesn't appear to include any coverage of older kernels, I'm not sure why I should be the guinea pig and take the risk! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 22:42 ` Andre McCurdy @ 2020-05-27 22:57 ` Khem Raj 2020-05-28 0:02 ` Khem Raj 0 siblings, 1 reply; 25+ messages in thread From: Khem Raj @ 2020-05-27 22:57 UTC (permalink / raw) To: Andre McCurdy Cc: Phil Blundell, Richard Purdie, Denys Dmytriyenko, Patches and discussions about the oe-core layer On Wed, May 27, 2020 at 3:43 PM Andre McCurdy <armccurdy@gmail.com> wrote: > > On Wed, May 27, 2020 at 2:52 PM Phil Blundell via > lists.openembedded.org <pb=pbcl.net@lists.openembedded.org> wrote: > > > > On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > > > and building userspace against way newer kernel-headers with older > > > kernel underneath has unintended > > > consequences. > > > > Can you be more specific? If this doesn't work, it's just a bug and > > should be fixed. What problems are you having? > > I don't have an up to date example, but I've been using kernel version > specific libc headers for all my projects for many years. The issue > which prompted me to do that was run time crashes from libcap-ng and > the historical commit message was: > > ---- > > linux-libc-headers: use 3.3.8 kernel header files for mips platforms > > If libcap-ng is unable to probe kernel capabilities at runtime then > it will assume the kernel supports all features defined by the libc > kernel headers. Since our default libc kernel headers (linux 3.14) > define capabilities which are not available in linux 3.3 based > stblinux kernel used for our MIPS platforms, that causes runtime > crashes. > > As a workaround, force an older version of linux-libc-headers for all > MIPS platforms to try to remove that discrepancy between the kernel's > capabilities and those defined in the libc kernel headers. > there are similar issues seen with linput.h using apps. I will dig the reasons but it does work when kernel and kernel header. versions are same and its using mainlne release for kernel headers here, so there is no vendor specific code perhaps that's breaking APIs > ---- > > The risk of using bleeding edge linux-libc-headers with an older > kernel may be low, it's not zero. Since OE testing doesn't appear to > include any coverage of older kernels, I'm not sure why I should be > the guinea pig and take the risk! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 22:57 ` Khem Raj @ 2020-05-28 0:02 ` Khem Raj 2020-05-28 9:01 ` Phil Blundell 0 siblings, 1 reply; 25+ messages in thread From: Khem Raj @ 2020-05-28 0:02 UTC (permalink / raw) To: Andre McCurdy Cc: Phil Blundell, Richard Purdie, Denys Dmytriyenko, Patches and discussions about the oe-core layer On Wed, May 27, 2020 at 3:57 PM Khem Raj <raj.khem@gmail.com> wrote: > > On Wed, May 27, 2020 at 3:43 PM Andre McCurdy <armccurdy@gmail.com> wrote: > > > > On Wed, May 27, 2020 at 2:52 PM Phil Blundell via > > lists.openembedded.org <pb=pbcl.net@lists.openembedded.org> wrote: > > > > > > On Wed, May 27, 2020 at 02:46:24PM -0700, Khem Raj wrote: > > > > and building userspace against way newer kernel-headers with older > > > > kernel underneath has unintended > > > > consequences. > > > > > > Can you be more specific? If this doesn't work, it's just a bug and > > > should be fixed. What problems are you having? > > > > I don't have an up to date example, but I've been using kernel version > > specific libc headers for all my projects for many years. The issue > > which prompted me to do that was run time crashes from libcap-ng and > > the historical commit message was: > > > > ---- > > > > linux-libc-headers: use 3.3.8 kernel header files for mips platforms > > > > If libcap-ng is unable to probe kernel capabilities at runtime then > > it will assume the kernel supports all features defined by the libc > > kernel headers. Since our default libc kernel headers (linux 3.14) > > define capabilities which are not available in linux 3.3 based > > stblinux kernel used for our MIPS platforms, that causes runtime > > crashes. > > > > As a workaround, force an older version of linux-libc-headers for all > > MIPS platforms to try to remove that discrepancy between the kernel's > > capabilities and those defined in the libc kernel headers. > > > > there are similar issues seen with linput.h using apps. I will dig the reasons > but it does work when kernel and kernel header. versions are same and its using > mainlne release for kernel headers here, so there is no vendor specific code > perhaps that's breaking APIs > 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. > > ---- > > > > The risk of using bleeding edge linux-libc-headers with an older > > kernel may be low, it's not zero. Since OE testing doesn't appear to > > include any coverage of older kernels, I'm not sure why I should be > > the guinea pig and take the risk! ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 0:02 ` Khem Raj @ 2020-05-28 9:01 ` Phil Blundell 2020-05-28 18:37 ` Khem Raj 0 siblings, 1 reply; 25+ messages in thread From: Phil Blundell @ 2020-05-28 9:01 UTC (permalink / raw) To: Khem Raj Cc: Andre McCurdy, Richard Purdie, Denys Dmytriyenko, Patches and discussions about the oe-core layer 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. p. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 9:01 ` Phil Blundell @ 2020-05-28 18:37 ` Khem Raj 0 siblings, 0 replies; 25+ messages in thread From: Khem Raj @ 2020-05-28 18:37 UTC (permalink / raw) To: Phil Blundell Cc: Andre McCurdy, Richard Purdie, Denys Dmytriyenko, Patches and discussions about the oe-core layer 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. > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 21:25 ` Richard Purdie 2020-05-27 21:46 ` Khem Raj @ 2020-05-27 23:11 ` Denys Dmytriyenko 2020-05-28 13:20 ` Richard Purdie 1 sibling, 1 reply; 25+ messages in thread From: Denys Dmytriyenko @ 2020-05-27 23:11 UTC (permalink / raw) To: Richard Purdie; +Cc: Khem Raj, openembedded-core On Wed, May 27, 2020 at 10:25:31PM +0100, Richard Purdie wrote: > On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > > > this helps in using common header across multiple versions of > > > kernel > > > going back > > > > This check should have been there from the beginning and for every > > header > > file. It's big PITA to sync this list up, especially when dealing > > with > > different glibc or kernel than OE-Core, e.g. external toolchains, > > etc. > > > > Any objections to making this check more generic for every entry in > > the list? > > Yes, a strong objection. We don't want to support or encourage every > kernel version out there. > > I also don't understand why people need to change the libc-headers > anyway :( Richard, I already explained my use-case with external toolchains - those usually come with specific set of libc-headers. And when those don't match the list from OE-Core, it causes problems, trying to support some resemblance of multilib. I believe that got disabled completely now for external-toolchains anyway... -- Denys ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 23:11 ` Denys Dmytriyenko @ 2020-05-28 13:20 ` Richard Purdie 2020-05-28 13:39 ` Adrian Bunk 2020-05-28 18:33 ` Khem Raj 0 siblings, 2 replies; 25+ messages in thread From: Richard Purdie @ 2020-05-28 13:20 UTC (permalink / raw) To: Denys Dmytriyenko; +Cc: Khem Raj, openembedded-core On Wed, 2020-05-27 at 19:11 -0400, Denys Dmytriyenko wrote: > On Wed, May 27, 2020 at 10:25:31PM +0100, Richard Purdie wrote: > > On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: > > > On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: > > > > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 > > > > ) > > > > this helps in using common header across multiple versions of > > > > kernel > > > > going back > > > > > > This check should have been there from the beginning and for > > > every > > > header > > > file. It's big PITA to sync this list up, especially when dealing > > > with > > > different glibc or kernel than OE-Core, e.g. external toolchains, > > > etc. > > > > > > Any objections to making this check more generic for every entry > > > in > > > the list? > > > > Yes, a strong objection. We don't want to support or encourage > > every > > kernel version out there. > > > > I also don't understand why people need to change the libc-headers > > anyway :( > > I already explained my use-case with external toolchains - those > usually come > with specific set of libc-headers. And when those don't match the > list from > OE-Core, it causes problems, trying to support some resemblance of > multilib. > I believe that got disabled completely now for external-toolchains > anyway... Right, external toolchains I can understand having specific version requirements. What I don't really understand is external toolchains would come with their own headers in most cases I can think of? Cheers, Richard ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 13:20 ` Richard Purdie @ 2020-05-28 13:39 ` Adrian Bunk 2020-05-28 17:38 ` Andre McCurdy 2020-05-28 18:31 ` Khem Raj 2020-05-28 18:33 ` Khem Raj 1 sibling, 2 replies; 25+ messages in thread From: Adrian Bunk @ 2020-05-28 13:39 UTC (permalink / raw) To: Richard Purdie; +Cc: Denys Dmytriyenko, Khem Raj, openembedded-core On Thu, May 28, 2020 at 02:20:02PM +0100, Richard Purdie wrote: > > Right, external toolchains I can understand having specific version > requirements. What I don't really understand is external toolchains > would come with their own headers in most cases I can think of? What I don't really understand is why kernel 4.1 was mentioned in the submission. At kernel 4.1 times the latest gcc was gcc 5. gcc 5 is not even supported as host gcc in master, and target builds are only tested with gcc 10. > Cheers, > > Richard cu Adrian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 13:39 ` Adrian Bunk @ 2020-05-28 17:38 ` Andre McCurdy 2020-05-28 19:04 ` Adrian Bunk 2020-05-28 21:33 ` Phil Blundell 2020-05-28 18:31 ` Khem Raj 1 sibling, 2 replies; 25+ messages in thread From: Andre McCurdy @ 2020-05-28 17:38 UTC (permalink / raw) To: Adrian Bunk Cc: Richard Purdie, Denys Dmytriyenko, Khem Raj, OE Core mailing list On Thu, May 28, 2020 at 6:39 AM Adrian Bunk <bunk@stusta.de> wrote: > > On Thu, May 28, 2020 at 02:20:02PM +0100, Richard Purdie wrote: > > > > Right, external toolchains I can understand having specific version > > requirements. What I don't really understand is external toolchains > > would come with their own headers in most cases I can think of? > > What I don't really understand is why kernel 4.1 was mentioned > in the submission. > > At kernel 4.1 times the latest gcc was gcc 5. > > gcc 5 is not even supported as host gcc in master, > and target builds are only tested with gcc 10. Is that an argument that users with an older vendor kernel should not update to newer versions of OE? Or that OE should provide older versions of gcc (in addition to the default) in order to support older kernels? And where does it leave OLDEST_KERNEL (currently set to 3.2.0)? If even kernel 4.1 is too old to be used with OE master then OLDEST_KERNEL looks like it should be updated to avoid giving users with older kernels false hope. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 17:38 ` Andre McCurdy @ 2020-05-28 19:04 ` Adrian Bunk 2020-05-28 19:30 ` Andre McCurdy 2020-05-28 21:33 ` Phil Blundell 1 sibling, 1 reply; 25+ messages in thread From: Adrian Bunk @ 2020-05-28 19:04 UTC (permalink / raw) To: Andre McCurdy Cc: Richard Purdie, Denys Dmytriyenko, Khem Raj, OE Core mailing list On Thu, May 28, 2020 at 10:38:15AM -0700, Andre McCurdy wrote: > On Thu, May 28, 2020 at 6:39 AM Adrian Bunk <bunk@stusta.de> wrote: > > > > On Thu, May 28, 2020 at 02:20:02PM +0100, Richard Purdie wrote: > > > > > > Right, external toolchains I can understand having specific version > > > requirements. What I don't really understand is external toolchains > > > would come with their own headers in most cases I can think of? > > > > What I don't really understand is why kernel 4.1 was mentioned > > in the submission. > > > > At kernel 4.1 times the latest gcc was gcc 5. > > > > gcc 5 is not even supported as host gcc in master, > > and target builds are only tested with gcc 10. > > Is that an argument that users with an older vendor kernel should not > update to newer versions of OE? Or that OE should provide older > versions of gcc (in addition to the default) in order to support older > kernels? It is an argument that ancient external toolchains will anyway not work. > And where does it leave OLDEST_KERNEL (currently set to 3.2.0)? OLDEST_KERNEL is just what is passed to glibc as lowest supported kernel, other OE components might have higher version requirements. > If even kernel 4.1 is too old to be used with OE master then > OLDEST_KERNEL looks like it should be updated to avoid giving users > with older kernels false hope. linux-libc-headers are the headers used by the C library in the toolchain, this is unrelated to the kernel running on the target. cu Adrian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 19:04 ` Adrian Bunk @ 2020-05-28 19:30 ` Andre McCurdy 2020-05-28 21:10 ` Phil Blundell 0 siblings, 1 reply; 25+ messages in thread From: Andre McCurdy @ 2020-05-28 19:30 UTC (permalink / raw) To: Adrian Bunk Cc: Richard Purdie, Denys Dmytriyenko, Khem Raj, OE Core mailing list On Thu, May 28, 2020 at 12:04 PM Adrian Bunk <bunk@stusta.de> wrote: > > On Thu, May 28, 2020 at 10:38:15AM -0700, Andre McCurdy wrote: > > On Thu, May 28, 2020 at 6:39 AM Adrian Bunk <bunk@stusta.de> wrote: > > > > > > On Thu, May 28, 2020 at 02:20:02PM +0100, Richard Purdie wrote: > > > > > > > > Right, external toolchains I can understand having specific version > > > > requirements. What I don't really understand is external toolchains > > > > would come with their own headers in most cases I can think of? > > > > > > What I don't really understand is why kernel 4.1 was mentioned > > > in the submission. > > > > > > At kernel 4.1 times the latest gcc was gcc 5. > > > > > > gcc 5 is not even supported as host gcc in master, > > > and target builds are only tested with gcc 10. > > > > Is that an argument that users with an older vendor kernel should not > > update to newer versions of OE? Or that OE should provide older > > versions of gcc (in addition to the default) in order to support older > > kernels? > > It is an argument that ancient external toolchains will anyway not work. > > > And where does it leave OLDEST_KERNEL (currently set to 3.2.0)? > > OLDEST_KERNEL is just what is passed to glibc as lowest supported kernel, > other OE components might have higher version requirements. > > > If even kernel 4.1 is too old to be used with OE master then > > OLDEST_KERNEL looks like it should be updated to avoid giving users > > with older kernels false hope. > > linux-libc-headers are the headers used by the C library in the > toolchain, this is unrelated to the kernel running on the target. All your statements are either well known information or already explained in the thread... What I was trying to get at is why you felt that bringing up the fact the kernel 4.1 was released at around the time gcc 5 was current is important? Presumably because you don't think people should be trying to use kernel 4.1 with gcc 10 in OE master? If so, then the logical conclusion is that either we should make that clearer (because it's not clear at the moment, especially for new users who don't fully understand how OLDEST_KERNEL is used) or provide an alternative (e.g. older versions of gcc) for users who can't follow the latest kernel but do want to follow the latest version of OE. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 19:30 ` Andre McCurdy @ 2020-05-28 21:10 ` Phil Blundell 0 siblings, 0 replies; 25+ messages in thread From: Phil Blundell @ 2020-05-28 21:10 UTC (permalink / raw) To: Andre McCurdy Cc: Adrian Bunk, Richard Purdie, Denys Dmytriyenko, Khem Raj, OE Core mailing list On Thu, May 28, 2020 at 12:30:13PM -0700, Andre McCurdy wrote: > What I was trying to get at is why you felt that bringing up the fact > the kernel 4.1 was released at around the time gcc 5 was current is > important? Agreed, I think this is a red herring. One of my current targets is in fact still using Linux 4.9, which I think was roughly contemporary with GCC 6, and it still builds just fine with at least GCC 8. Although I think some of our old-timers still carry the emotional scars associated with gcc 2.8, in reality the days when a compiler upgrade ought to be expected to break the kernel in anything other than a trivial way (i.e. new warning or error that's easy to patch) are long gone. And, all that said, there is plenty of precedent for OE users keeping older versions of GCC around in order to support particular pieces of software that didn't work with newer compilers for whatever reason. It's not generally all that difficult, and anybody who was sufficiently interested could keep the old gcc version around in a separate layer even after it's deleted from oe-core. In fact oe-core did at one point even have an explicit KERNEL_CCSUFFIX variable which users could set if they wanted a specific gcc version to go with their kernel, but this was deleted in 2013 with the justification "kernel compiler is not special". p. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 17:38 ` Andre McCurdy 2020-05-28 19:04 ` Adrian Bunk @ 2020-05-28 21:33 ` Phil Blundell 1 sibling, 0 replies; 25+ messages in thread From: Phil Blundell @ 2020-05-28 21:33 UTC (permalink / raw) To: Andre McCurdy Cc: Adrian Bunk, Richard Purdie, Denys Dmytriyenko, Khem Raj, OE Core mailing list On Thu, May 28, 2020 at 10:38:15AM -0700, Andre McCurdy wrote: > And where does it leave OLDEST_KERNEL (currently set to 3.2.0)? If > even kernel 4.1 is too old to be used with OE master then > OLDEST_KERNEL looks like it should be updated to avoid giving users > with older kernels false hope. Yes. Ultimately, OLDEST_KERNEL is really a distro decision, but it shouldn't be set to an unnecessarily old version. Glibc in particular uses that variable to decide how much compatibility code it needs to include to support old kernels, and there is sometimes a runtime performance cost associated with that. And as you say, if a user sees OLDEST_KERNEL = "3.2.0" then one couldn't really blame them for assuming that this means they can use such a kernel. I don't personally know any reason why a 3.2 kernel wouldn't work just fine with most of oe-core, and I think that's still the minimum required kernel version for the current version of glibc, but perhaps others know of reasons why newer kernels are nowadays needed. p. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 13:39 ` Adrian Bunk 2020-05-28 17:38 ` Andre McCurdy @ 2020-05-28 18:31 ` Khem Raj 1 sibling, 0 replies; 25+ messages in thread From: Khem Raj @ 2020-05-28 18:31 UTC (permalink / raw) To: Adrian Bunk, Richard Purdie; +Cc: Denys Dmytriyenko, openembedded-core On 5/28/20 6:39 AM, Adrian Bunk wrote: > On Thu, May 28, 2020 at 02:20:02PM +0100, Richard Purdie wrote: >> >> Right, external toolchains I can understand having specific version >> requirements. What I don't really understand is external toolchains >> would come with their own headers in most cases I can think of? > > What I don't really understand is why kernel 4.1 was mentioned > in the submission. it is set as an example when using kernel 4.1 to provide kernel headers, since its a .inc file it can be includes by other linux-libc-headers recipes, if thats not the intention then it should be merged into .bb and intent made clear. > > At kernel 4.1 times the latest gcc was gcc 5. > > gcc 5 is not even supported as host gcc in master, > and target builds are only tested with gcc 10. > what is this statement for ? >> Cheers, >> >> Richard > > cu > Adrian > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 13:20 ` Richard Purdie 2020-05-28 13:39 ` Adrian Bunk @ 2020-05-28 18:33 ` Khem Raj 2020-05-28 20:10 ` Adrian Bunk 1 sibling, 1 reply; 25+ messages in thread From: Khem Raj @ 2020-05-28 18:33 UTC (permalink / raw) To: Richard Purdie, Denys Dmytriyenko; +Cc: openembedded-core On 5/28/20 6:20 AM, Richard Purdie wrote: > On Wed, 2020-05-27 at 19:11 -0400, Denys Dmytriyenko wrote: >> On Wed, May 27, 2020 at 10:25:31PM +0100, Richard Purdie wrote: >>> On Wed, 2020-05-27 at 11:59 -0400, Denys Dmytriyenko wrote: >>>> On Wed, May 27, 2020 at 08:50:11AM -0700, Khem Raj wrote: >>>>> asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 >>>>> ) >>>>> this helps in using common header across multiple versions of >>>>> kernel >>>>> going back >>>> >>>> This check should have been there from the beginning and for >>>> every >>>> header >>>> file. It's big PITA to sync this list up, especially when dealing >>>> with >>>> different glibc or kernel than OE-Core, e.g. external toolchains, >>>> etc. >>>> >>>> Any objections to making this check more generic for every entry >>>> in >>>> the list? >>> >>> Yes, a strong objection. We don't want to support or encourage >>> every >>> kernel version out there. >>> >>> I also don't understand why people need to change the libc-headers >>> anyway :( >> >> I already explained my use-case with external toolchains - those >> usually come >> with specific set of libc-headers. And when those don't match the >> list from >> OE-Core, it causes problems, trying to support some resemblance of >> multilib. >> I believe that got disabled completely now for external-toolchains >> anyway... > > Right, external toolchains I can understand having specific version > requirements. What I don't really understand is external toolchains > would come with their own headers in most cases I can think of? > this is not a freestanding toolchain, but hosted one, so they need to provide OS (linux) headers. think of case where apps are build just by using this toolchain outside OE, app devs are not expected to provide these headers. > Cheers, > > Richard > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-28 18:33 ` Khem Raj @ 2020-05-28 20:10 ` Adrian Bunk 0 siblings, 0 replies; 25+ messages in thread From: Adrian Bunk @ 2020-05-28 20:10 UTC (permalink / raw) To: Khem Raj; +Cc: Richard Purdie, Denys Dmytriyenko, openembedded-core On Thu, May 28, 2020 at 11:33:45AM -0700, Khem Raj wrote: > > this is not a freestanding toolchain, but hosted one, so they need to > provide OS (linux) headers. think of case where apps are build just by > using this toolchain outside OE, app devs are not expected to provide these > headers. Various gcc libraries like libgcc or libstdc++ might be used on the target. What C library was used for building these gcc libraries? What kernel headers are used by this C library in the toolchain? cu Adrian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing 2020-05-27 15:50 [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing Khem Raj 2020-05-27 15:59 ` [OE-core] " Denys Dmytriyenko @ 2020-05-27 21:20 ` Richard Purdie 1 sibling, 0 replies; 25+ messages in thread From: Richard Purdie @ 2020-05-27 21:20 UTC (permalink / raw) To: Khem Raj, openembedded-core On Wed, 2020-05-27 at 08:50 -0700, Khem Raj wrote: > asm/bpf_perf_event.h does not exist in older kernels e.g. ( 4.1 ) > this helps in using common header across multiple versions of kernel > going back > > Signed-off-by: Khem Raj <raj.khem@gmail.com> > --- > .../recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > index 4481aa430c..933a01ba81 100644 > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc > @@ -81,8 +81,11 @@ do_install_append_armeb () { > } > > do_install_armmultilib () { > - oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h asm/bpf_perf_event.h > + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/kvm_para.h asm/mman.h asm/param.h asm/perf_regs.h > oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h asm/swab.h asm/types.h asm/unistd.h > + if [ -f "${D}/${includedir}/asm/bpf_perf_event.h" ]; then > + oe_multilib_header asm/bpf_perf_event.h > + fi > } Why are people using old linux-libc-headers? This is for the toolchain so it doesn't need to have anything to do with the target kernel. I've always assumed that people should be able to use the latest version here and should not need to customise this. The headers should be backwards compatible. What am I missing? Cheers, Richard ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2020-05-28 21:33 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-27 15:50 [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing Khem Raj 2020-05-27 15:59 ` [OE-core] " Denys Dmytriyenko 2020-05-27 20:45 ` Khem Raj 2020-05-27 20:56 ` Andre McCurdy 2020-05-27 21:25 ` Richard Purdie 2020-05-27 21:46 ` Khem Raj 2020-05-27 21:50 ` Richard Purdie 2020-05-27 21:52 ` Phil Blundell 2020-05-27 22:42 ` Andre McCurdy 2020-05-27 22:57 ` Khem Raj 2020-05-28 0:02 ` Khem Raj 2020-05-28 9:01 ` Phil Blundell 2020-05-28 18:37 ` Khem Raj 2020-05-27 23:11 ` Denys Dmytriyenko 2020-05-28 13:20 ` Richard Purdie 2020-05-28 13:39 ` Adrian Bunk 2020-05-28 17:38 ` Andre McCurdy 2020-05-28 19:04 ` Adrian Bunk 2020-05-28 19:30 ` Andre McCurdy 2020-05-28 21:10 ` Phil Blundell 2020-05-28 21:33 ` Phil Blundell 2020-05-28 18:31 ` Khem Raj 2020-05-28 18:33 ` Khem Raj 2020-05-28 20:10 ` Adrian Bunk 2020-05-27 21:20 ` Richard Purdie
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.