Patchwork [1/2] bitbake.conf: update OLDEST_KERNEL to 2.6.0

login
register
mail settings
Submitter Paul Eggleton
Date July 7, 2011, 1:11 p.m.
Message ID <b53c3209e62b53c744afeed13e1563932770cf1f.1310044227.git.paul.eggleton@linux.intel.com>
Download mbox | patch
Permalink /patch/7131/
State Superseded
Headers show

Comments

Paul Eggleton - July 7, 2011, 1:11 p.m.
Since we no longer support 2.4, update this setting to 2.6.0. (This affects
eglibc's kernel support).

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/conf/bitbake.conf |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Koen Kooi - July 7, 2011, 2:24 p.m.
angstrom has been setting it to 2.6.16 for some years now, I forget which bug that fixed over 2.6.0

Op 7 jul. 2011 om 14:11 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> Since we no longer support 2.4, update this setting to 2.6.0. (This affects
> eglibc's kernel support).
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
> meta/conf/bitbake.conf |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index bdaa35d..56a867b 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -349,7 +349,7 @@ SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
> # Kernel info.
> ##################################################################
> 
> -OLDEST_KERNEL = "2.4.0"
> +OLDEST_KERNEL = "2.6.0"
> STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel"
> 
> ##################################################################
> -- 
> 1.7.4.1
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Paul Eggleton - July 7, 2011, 2:34 p.m.
On Thursday 07 July 2011 15:24:46 Koen Kooi wrote:
> angstrom has been setting it to 2.6.16 for some years now, I forget which
> bug that fixed over 2.6.0

Personally I don't know enough about which crusty old 2.6 kernels people are 
still using out there, so I figured 2.6.0 was the safest bet.

A trawl of the OE history turns up these two:

-----------------------------------
commit 8b0202e6e3f90a772df301e8522f9deb03e50132
Author: Tom Rini <tom_rini@mentor.com>
Date:   Wed Mar 3 12:17:38 2010 -0700

    glibc*.inc: Bump OLDEST_KERNEL to 2.6.16
    
    Per glibc's ChangeLog, 2.6.16 is the minimum required by at least glibc
    2.9 
    Prior to this, it was a murky 2.6.14 + patches to 2.6.16 (when it was all
    upstream).
-----------------------------------
commit 794e8652f5c4fef71a8b9ab834b39f75b99f9420
Author: Koen Kooi <koen@openembedded.org>
Date:   Thu May 21 20:30:37 2009 +0200

    Angstrom 2009.X: set OLDEST_KERNEL to 2.6.16 to avoid problems with 
ppoll()
-----------------------------------

Any further comments/info? Should we be using 2.6.16 in oe-core as well?

Cheers,
Paul
Richard Purdie - July 7, 2011, 11:15 p.m.
On Thu, 2011-07-07 at 15:34 +0100, Paul Eggleton wrote:
> On Thursday 07 July 2011 15:24:46 Koen Kooi wrote:
> > angstrom has been setting it to 2.6.16 for some years now, I forget which
> > bug that fixed over 2.6.0
> 
> Personally I don't know enough about which crusty old 2.6 kernels people are 
> still using out there, so I figured 2.6.0 was the safest bet.
> 
> A trawl of the OE history turns up these two:
> 
> -----------------------------------
> commit 8b0202e6e3f90a772df301e8522f9deb03e50132
> Author: Tom Rini <tom_rini@mentor.com>
> Date:   Wed Mar 3 12:17:38 2010 -0700
> 
>     glibc*.inc: Bump OLDEST_KERNEL to 2.6.16
>     
>     Per glibc's ChangeLog, 2.6.16 is the minimum required by at least glibc
>     2.9 
>     Prior to this, it was a murky 2.6.14 + patches to 2.6.16 (when it was all
>     upstream).
> -----------------------------------
> commit 794e8652f5c4fef71a8b9ab834b39f75b99f9420
> Author: Koen Kooi <koen@openembedded.org>
> Date:   Thu May 21 20:30:37 2009 +0200
> 
>     Angstrom 2009.X: set OLDEST_KERNEL to 2.6.16 to avoid problems with 
> ppoll()
> -----------------------------------
> 
> Any further comments/info? Should we be using 2.6.16 in oe-core as well?

I'd suggest yes...

Cheers,

Richard
Khem Raj - July 8, 2011, 5:21 a.m.
On 07/07/2011 07:34 AM, Paul Eggleton wrote:
> On Thursday 07 July 2011 15:24:46 Koen Kooi wrote:
>> angstrom has been setting it to 2.6.16 for some years now, I forget which
>> bug that fixed over 2.6.0
>
> Personally I don't know enough about which crusty old 2.6 kernels people are
> still using out there, so I figured 2.6.0 was the safest bet.

If oe-core never supported older kernel than 2.6.37 then setting it to 
2.6.37 would be better IMO

>
> A trawl of the OE history turns up these two:
>
> -----------------------------------
> commit 8b0202e6e3f90a772df301e8522f9deb03e50132
> Author: Tom Rini<tom_rini@mentor.com>
> Date:   Wed Mar 3 12:17:38 2010 -0700
>
>      glibc*.inc: Bump OLDEST_KERNEL to 2.6.16
>
>      Per glibc's ChangeLog, 2.6.16 is the minimum required by at least glibc
>      2.9
>      Prior to this, it was a murky 2.6.14 + patches to 2.6.16 (when it was all
>      upstream).
> -----------------------------------
> commit 794e8652f5c4fef71a8b9ab834b39f75b99f9420
> Author: Koen Kooi<koen@openembedded.org>
> Date:   Thu May 21 20:30:37 2009 +0200
>
>      Angstrom 2009.X: set OLDEST_KERNEL to 2.6.16 to avoid problems with
> ppoll()
> -----------------------------------
>
> Any further comments/info? Should we be using 2.6.16 in oe-core as well?
>
> Cheers,
> Paul
>
Paul Eggleton - July 8, 2011, 8:38 a.m.
On Friday 08 July 2011 06:21:16 Khem Raj wrote:
> If oe-core never supported older kernel than 2.6.37 then setting it to
> 2.6.37 would be better IMO

It's not necessarily just about oe-core - it's about what layers get used on 
top, and some of those will be using kernels older than 2.6.37.

Cheers,
Paul
Chris Elston - July 8, 2011, 8:46 a.m.
On Fri, 2011-07-08 at 09:38 +0100, Paul Eggleton wrote:
> On Friday 08 July 2011 06:21:16 Khem Raj wrote:
> > If oe-core never supported older kernel than 2.6.37 then setting it to
> > 2.6.37 would be better IMO
> 
> It's not necessarily just about oe-core - it's about what layers get used on 
> top, and some of those will be using kernels older than 2.6.37.

It's very rare that we get a free hand in the choice of kernel version.
We get stuck with whichever version the silicon vendor chooses to
support, so it would be bad for us if we couldn't use an older kernel in
our layers.

Cheers,

Chris.
Paul Eggleton - July 8, 2011, 9:49 a.m.
On Friday 08 July 2011 09:46:34 Chris Elston wrote:
> It's very rare that we get a free hand in the choice of kernel version.
> We get stuck with whichever version the silicon vendor chooses to
> support, so it would be bad for us if we couldn't use an older kernel in
> our layers.

Just out of interest, what's the oldest kernel you have to deal with in your 
current/recent projects?

Cheers,
Paul
Phil Blundell - July 8, 2011, 9:53 a.m.
On Fri, 2011-07-08 at 09:38 +0100, Paul Eggleton wrote:
> On Friday 08 July 2011 06:21:16 Khem Raj wrote:
> > If oe-core never supported older kernel than 2.6.37 then setting it to
> > 2.6.37 would be better IMO
> 
> It's not necessarily just about oe-core - it's about what layers get used on 
> top, and some of those will be using kernels older than 2.6.37.

They can always provide their own OLDEST_KERNEL setting, though.  To
some extent I think it's a bit academic what the default in oe-core is.

p.
Paul Eggleton - July 8, 2011, 10:03 a.m.
On Friday 08 July 2011 10:53:49 Phil Blundell wrote:
> They can always provide their own OLDEST_KERNEL setting, though.  To
> some extent I think it's a bit academic what the default in oe-core is.

Yes, but let's have a sensible default value, in particular that will allow 
the majority not to experience subtle problems that they will have to spend 
time tracking down. Many people coming to OE fresh will not know this setting 
even exists - I only discovered it the other day by accident.

Cheers,
Paul
Phil Blundell - July 8, 2011, 10:12 a.m.
On Fri, 2011-07-08 at 11:03 +0100, Paul Eggleton wrote:
> On Friday 08 July 2011 10:53:49 Phil Blundell wrote:
> > They can always provide their own OLDEST_KERNEL setting, though.  To
> > some extent I think it's a bit academic what the default in oe-core is.
> 
> Yes, but let's have a sensible default value, in particular that will allow 
> the majority not to experience subtle problems that they will have to spend 
> time tracking down. Many people coming to OE fresh will not know this setting 
> even exists - I only discovered it the other day by accident.

If OLDEST_KERNEL is set to a value that's too new then the failure you
get is anything but subtle: glibc will just print "kernel too old" and
exit.  I guess we could enhance that message to refer directly to
OLDEST_KERNEL to make it a bit more obvious what you need to do.  Also,
we could teach kernel.bbclass to issue a diagnostic if you try to build
a kernel that's older than OLDEST_KERNEL.

p.
Paul Eggleton - July 8, 2011, 10:20 a.m.
On Friday 08 July 2011 11:12:12 Phil Blundell wrote:
> If OLDEST_KERNEL is set to a value that's too new then the failure you
> get is anything but subtle: glibc will just print "kernel too old" and
> exit.

OK, I had just assumed you would just get errors about missing syscalls, good 
to know that it would be more obvious than that.

> I guess we could enhance that message to refer directly to
> OLDEST_KERNEL to make it a bit more obvious what you need to do.
> Also, we could teach kernel.bbclass to issue a diagnostic if you try to
> build a kernel that's older than OLDEST_KERNEL.

These sound like good ideas. I'll add them to my todo list to have a look at 
if nobody else gets there first.

Cheers,
Paul
Khem Raj - July 8, 2011, 2:17 p.m.
On Fri, Jul 8, 2011 at 1:38 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Friday 08 July 2011 06:21:16 Khem Raj wrote:
>> If oe-core never supported older kernel than 2.6.37 then setting it to
>> 2.6.37 would be better IMO
>
> It's not necessarily just about oe-core - it's about what layers get used on
> top, and some of those will be using kernels older than 2.6.37.

Its similar to  a situation where some of the layers might be using
gcc older than 4.6.0 but we still chose 4.6.0
in default distro vars. There always is a possibility to override it
if user has to.

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
Richard Purdie - July 8, 2011, 4:28 p.m.
On Fri, 2011-07-08 at 07:17 -0700, Khem Raj wrote:
> On Fri, Jul 8, 2011 at 1:38 AM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Friday 08 July 2011 06:21:16 Khem Raj wrote:
> >> If oe-core never supported older kernel than 2.6.37 then setting it to
> >> 2.6.37 would be better IMO
> >
> > It's not necessarily just about oe-core - it's about what layers get used on
> > top, and some of those will be using kernels older than 2.6.37.
> 
> Its similar to  a situation where some of the layers might be using
> gcc older than 4.6.0 but we still chose 4.6.0
> in default distro vars. There always is a possibility to override it
> if user has to.

For now, I've merged the 2.6.16 patch since there seem to be good
reasons for making things at least that recent. Its certainly better
than 2.4! :)

Cheers,

Richard

Patch

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index bdaa35d..56a867b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -349,7 +349,7 @@  SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
 # Kernel info.
 ##################################################################
 
-OLDEST_KERNEL = "2.4.0"
+OLDEST_KERNEL = "2.6.0"
 STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel"
 
 ##################################################################