[PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Denys Dmytriyenko]

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
> 

> 

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Khem Raj]

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
> >
>
> > 
>

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Andre McCurdy]

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
> > >
> >
> > >
> >
> 

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Richard Purdie]

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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Richard Purdie]

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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Khem Raj]

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
>

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Richard Purdie]

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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Phil Blundell]

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.

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Andre McCurdy]

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!

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Khem Raj]

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!

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Denys Dmytriyenko]

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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Khem Raj]

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!

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Phil Blundell]

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.

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Richard Purdie]

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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Adrian Bunk]

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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Andre McCurdy]

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.

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Khem Raj]

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
> 

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Khem Raj]

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
> 
> 

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Khem Raj]

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.
> 

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Adrian Bunk]

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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Andre McCurdy]

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.

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Adrian Bunk]

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

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Phil Blundell]

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.

Re: [OE-core] [PATCH] linux-libc-headers: Check for asm/bpf_perf_event.h before multilibbing

[Phil Blundell]

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.