[PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Richard Purdie]

I'm getting concerned with the number of people forking this recipe
and not understanding what they're doing. I'm therefore proposing
adding in a suitable warning to people thinking of copying it.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
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 96fe2ff..79b7dc4 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -2,6 +2,28 @@ DESCRIPTION = "Sanitized set of kernel headers for the C library's use."
 SECTION = "devel"
 LICENSE = "GPLv2"
 
+#########################################################################
+####                        PLEASE READ 
+#########################################################################
+#
+# You're probably looking here thinking you need to create some new copy
+# of linux-libc-headers since you have your own custom kernel. To put 
+# this simply, you DO NOT.
+#
+# Why? These headers are used to build the libc. If you customise the 
+# headers you are customising the libc and the libc becomes machine
+# specific. Most people do not add custom libc extensions to the kernel
+# and have a machine specific libc.
+#
+# But you have some kernel headers you need for some driver? That is fine
+# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
+# This will make the package using them machine specific but this is much
+# better than having a maching specific C library. This does mean your 
+# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
+# makes total sense.
+#
+# -- RP
+
 LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
 
 python __anonymous () {

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2568 bytes --]

On Friday, September 13, 2013, Richard Purdie wrote:

> I'm getting concerned with the number of people forking this recipe
> and not understanding what they're doing. I'm therefore proposing
> adding in a suitable warning to people thinking of copying it.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org<javascript:;>
> >
> ---
> 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 96fe2ff..79b7dc4 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> @@ -2,6 +2,28 @@ DESCRIPTION = "Sanitized set of kernel headers for the C
> library's use."
>  SECTION = "devel"
>  LICENSE = "GPLv2"
>
> +#########################################################################
> +####                        PLEASE READ
> +#########################################################################
> +#
> +# You're probably looking here thinking you need to create some new copy
> +# of linux-libc-headers since you have your own custom kernel. To put
> +# this simply, you DO NOT.
> +#
> +# Why? These headers are used to build the libc. If you customise the
> +# headers you are customising the libc and the libc becomes machine
> +# specific. Most people do not add custom libc extensions to the kernel
> +# and have a machine specific libc.
> +#
> +# But you have some kernel headers you need for some driver? That is fine
> +# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
> +# This will make the package using them machine specific but this is much
> +# better than having a maching specific C library. This does mean your
> +# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
> +# makes total sense.
> +#
> +# -- RP


There are cases where we have bsps with 2.6.3x kernels and libc compiled
against 3.10 assumes syscalls
Which the kernel will not provide. These kinds are genuine cases for
creating equivalent recipes
You should mention the valid case too in this notice and basically asses
the user is knowing what. He is doing

+
>  LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>
>  python __anonymous () {
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org <javascript:;>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 3329 bytes --]

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Phil Blundell]

On Fri, 2013-09-13 at 21:24 -0700, Khem Raj wrote:
> There are cases where we have bsps with 2.6.3x kernels and libc
> compiled against 3.10 assumes syscalls

That is a bug in glibc.  It should not be doing that unless configured
--enable-kernel=3.10.x (and this is the whole point of the
--enable-kernel option).  If it's assuming 3.10.x syscalls under
--enable-kernel=2.6.x then it is broken and should be fixed. 

p.

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Khem Raj]

On Sat, Sep 14, 2013 at 12:19 AM, Phil Blundell <pb@pbcl.net> wrote:
> On Fri, 2013-09-13 at 21:24 -0700, Khem Raj wrote:
>> There are cases where we have bsps with 2.6.3x kernels and libc
>> compiled against 3.10 assumes syscalls
>
> That is a bug in glibc.  It should not be doing that unless configured
> --enable-kernel=3.10.x (and this is the whole point of the
> --enable-kernel option).  If it's assuming 3.10.x syscalls under
> --enable-kernel=2.6.x then it is broken and should be fixed.
>

we have OLDEST_KERNEL = "2.6.16" and thats not a problem. However one
case where it showed up was when building udev > 164 with kernels
where accept4 call was not wired for arm e.g. since udev looked up
definition of SOCK_CLOEXEC which it found but that 2.6.32 kernel
really did not support it.

> p.
>
>
>

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Phil Blundell]

On Mon, 2013-09-16 at 09:24 -0700, Khem Raj wrote:
> On Sat, Sep 14, 2013 at 12:19 AM, Phil Blundell <pb@pbcl.net> wrote:
> > On Fri, 2013-09-13 at 21:24 -0700, Khem Raj wrote:
> >> There are cases where we have bsps with 2.6.3x kernels and libc
> >> compiled against 3.10 assumes syscalls
> >
> > That is a bug in glibc.  It should not be doing that unless configured
> > --enable-kernel=3.10.x (and this is the whole point of the
> > --enable-kernel option).  If it's assuming 3.10.x syscalls under
> > --enable-kernel=2.6.x then it is broken and should be fixed.
> >
> 
> we have OLDEST_KERNEL = "2.6.16" and thats not a problem. However one
> case where it showed up was when building udev > 164 with kernels
> where accept4 call was not wired for arm e.g. since udev looked up
> definition of SOCK_CLOEXEC which it found but that 2.6.32 kernel
> really did not support it.

That sounds slightly different to the problem you were originally
describing ("libc compiled against 3.10") but I think the answer is
basically still the same: it is a bug in udev, and udev ought to be
fixed.

p.

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Monday, September 16, 2013, Phil Blundell <pb@pbcl.net> wrote:
> On Mon, 2013-09-16 at 09:24 -0700, Khem Raj wrote:
>> On Sat, Sep 14, 2013 at 12:19 AM, Phil Blundell <pb@pbcl.net> wrote:
>> > On Fri, 2013-09-13 at 21:24 -0700, Khem Raj wrote:
>> >> There are cases where we have bsps with 2.6.3x kernels and libc
>> >> compiled against 3.10 assumes syscalls
>> >
>> > That is a bug in glibc.  It should not be doing that unless configured
>> > --enable-kernel=3.10.x (and this is the whole point of the
>> > --enable-kernel option).  If it's assuming 3.10.x syscalls under
>> > --enable-kernel=2.6.x then it is broken and should be fixed.
>> >
>>
>> we have OLDEST_KERNEL = "2.6.16" and thats not a problem. However one
>> case where it showed up was when building udev > 164 with kernels
>> where accept4 call was not wired for arm e.g. since udev looked up
>> definition of SOCK_CLOEXEC which it found but that 2.6.32 kernel
>> really did not support it.
>
> That sounds slightly different to the problem you were originally
> describing ("libc compiled against 3.10") but I think the answer is
> basically still the same: it is a bug in udev, and udev ought to be
> fixed.
>

if you check for kernel version yes but its not wrong by testing a given
kernel API which it is doing

anyway i think the notice that rp added is good in general and may be will
help folks to upgrade and unify kernels in long run
> p.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1807 bytes --]

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Anders Darander]

* Khem Raj <raj.khem@gmail.com> [130914 06:24]:



> On Friday, September 13, 2013, Richard Purdie wrote:

>     I'm getting concerned with the number of people forking this recipe
>     and not understanding what they're doing. I'm therefore proposing
>     adding in a suitable warning to people thinking of copying it.

>     Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>     ---
>     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 96fe2ff..79b7dc4 100644
>     --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>     +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>     @@ -2,6 +2,28 @@ DESCRIPTION = "Sanitized set of kernel headers for the C
>     library's use."
>      SECTION = "devel"
>      LICENSE = "GPLv2"

>     +#########################################################################
>     +####                        PLEASE READ
>     +#########################################################################
>     +#
>     +# You're probably looking here thinking you need to create some new copy
>     +# of linux-libc-headers since you have your own custom kernel. To put
>     +# this simply, you DO NOT.
>     +#
>     +# Why? These headers are used to build the libc. If you customise the
>     +# headers you are customising the libc and the libc becomes machine
>     +# specific. Most people do not add custom libc extensions to the kernel
>     +# and have a machine specific libc.
>     +#
>     +# But you have some kernel headers you need for some driver? That is fine
>     +# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
>     +# This will make the package using them machine specific but this is much
>     +# better than having a maching specific C library. This does mean your
>     +# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
>     +# makes total sense.
>     +#
>     +# -- RP


> There are cases where we have bsps with 2.6.3x kernels and libc compiled
> against 3.10 assumes syscalls
> Which the kernel will not provide. These kinds are genuine cases for creating
> equivalent recipes
> You should mention the valid case too in this notice and basically asses the
> user is knowing what. He is doing

I'd be inclined to say that anyone working on / adding a bsp that needs
this, will (hopefully) understand this anyway. If you know that
3.x-based kernel headers aren't working, you're going to add a patched
linux-libc-headers regardless of the warning above.

Cheers,
Ander

-- 
Anders Darander
ChargeStorm AB / eStorm AB

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Anders Darander]

* Richard Purdie <richard.purdie@linuxfoundation.org> [130913 13:18]:

> I'm getting concerned with the number of people forking this recipe
> and not understanding what they're doing. I'm therefore proposing
> adding in a suitable warning to people thinking of copying it.

> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Acked-by: Anders Darander <anders@chargestorm.se>

-- 
Anders Darander
ChargeStorm AB / eStorm AB

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Bruce Ashfield]

On Fri, Sep 13, 2013 at 7:18 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I'm getting concerned with the number of people forking this recipe
> and not understanding what they're doing. I'm therefore proposing
> adding in a suitable warning to people thinking of copying it.
>

This definitely has my vote. Its an issue that I'm constantly
explaining as well.

Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>



> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> 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 96fe2ff..79b7dc4 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> @@ -2,6 +2,28 @@ DESCRIPTION = "Sanitized set of kernel headers for the C library's use."
>  SECTION = "devel"
>  LICENSE = "GPLv2"
>
> +#########################################################################
> +####                        PLEASE READ
> +#########################################################################
> +#
> +# You're probably looking here thinking you need to create some new copy
> +# of linux-libc-headers since you have your own custom kernel. To put
> +# this simply, you DO NOT.
> +#
> +# Why? These headers are used to build the libc. If you customise the
> +# headers you are customising the libc and the libc becomes machine
> +# specific. Most people do not add custom libc extensions to the kernel
> +# and have a machine specific libc.
> +#
> +# But you have some kernel headers you need for some driver? That is fine
> +# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
> +# This will make the package using them machine specific but this is much
> +# better than having a maching specific C library. This does mean your
> +# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
> +# makes total sense.
> +#
> +# -- RP
> +
>  LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>
>  python __anonymous () {
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Mark Hatle]

On 9/13/13 6:18 AM, Richard Purdie wrote:
> I'm getting concerned with the number of people forking this recipe
> and not understanding what they're doing. I'm therefore proposing
> adding in a suitable warning to people thinking of copying it.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> 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 96fe2ff..79b7dc4 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> @@ -2,6 +2,28 @@ DESCRIPTION = "Sanitized set of kernel headers for the C library's use."
>   SECTION = "devel"
>   LICENSE = "GPLv2"
>
> +#########################################################################
> +####                        PLEASE READ
> +#########################################################################
> +#
> +# You're probably looking here thinking you need to create some new copy
> +# of linux-libc-headers since you have your own custom kernel. To put
> +# this simply, you DO NOT.
> +#
> +# Why? These headers are used to build the libc. If you customise the
> +# headers you are customising the libc and the libc becomes machine
> +# specific. Most people do not add custom libc extensions to the kernel
> +# and have a machine specific libc.
> +#
> +# But you have some kernel headers you need for some driver? That is fine
> +# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
> +# This will make the package using them machine specific but this is much
> +# better than having a maching specific C library. This does mean your

Typo in the above, "maching" should be "machine"...

> +# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
> +# makes total sense.
> +#
> +# -- RP
> +

I am completely in favor of this.  People don't get that custom kernel headers 
have severe ramifications in projects.  I've had to explain this to hundreds 
over the last few years (and they keep doing it anyway)..

Acked-by: Mark Hatle  (with change mentioned above)

--Mark

>   LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>
>   python __anonymous () {
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [PATCH] linux-libc-headers: Add big warning about antisocial behaviour

[Hans Beckérus]

On Mon, Sep 16, 2013 at 5:47 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> On 9/13/13 6:18 AM, Richard Purdie wrote:
>>
>> I'm getting concerned with the number of people forking this recipe
>> and not understanding what they're doing. I'm therefore proposing
>> adding in a suitable warning to people thinking of copying it.
>>
>> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>> ---
>> 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 96fe2ff..79b7dc4 100644
>> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> @@ -2,6 +2,28 @@ DESCRIPTION = "Sanitized set of kernel headers for the C
>> library's use."
>>   SECTION = "devel"
>>   LICENSE = "GPLv2"
>>
>> +#########################################################################
>> +####                        PLEASE READ
>> +#########################################################################
>> +#
>> +# You're probably looking here thinking you need to create some new copy
>> +# of linux-libc-headers since you have your own custom kernel. To put
>> +# this simply, you DO NOT.
>> +#
>> +# Why? These headers are used to build the libc. If you customise the
>> +# headers you are customising the libc and the libc becomes machine
>> +# specific. Most people do not add custom libc extensions to the kernel
>> +# and have a machine specific libc.
>> +#
>> +# But you have some kernel headers you need for some driver? That is fine
>> +# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
>> +# This will make the package using them machine specific but this is much
>> +# better than having a maching specific C library. This does mean your
>
>
> Typo in the above, "maching" should be "machine"...
>
>
>> +# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
>> +# makes total sense.
>> +#
>> +# -- RP
>> +
>
>
> I am completely in favor of this.  People don't get that custom kernel
> headers have severe ramifications in projects.  I've had to explain this to
> hundreds over the last few years (and they keep doing it anyway)..
>
> Acked-by: Mark Hatle  (with change mentioned above)
>
> --Mark
>
I can only agree to that what you are saying makes perfectly sense. Do
not fix what is not broken ;)
However, we did stumble into one problem when stepping up to a later
baseline using a 3.8 kernel. The patch for Makefile.headerinst could
not be applied to our vendor specific 3.6 kernel branch so we were
force to disable it completely. Did we take the wrong turn somewhere?

Thanks.
Hans


>
>>   LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>
>>   python __anonymous () {
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core