| 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
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
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
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
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 >
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
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.
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
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.
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
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.
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
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 >
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" ##################################################################
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(-)