RFC: provide 3.0.x and 3.1 libc headers
cover RFC: provide 3.0.x and 3.1 libc headers
Hi all,
Here's a RFC patch for updating the toolchain linux-libc headers to 3.x variants.
The reason I'm calling it a RFC is:
- I wrote some anonymous python code (and I'm no python coder) to deal with 2.6 / 3.0 tgz location differences. This could have also been done with a variable set in the recipes and used by the .inc. I wasn't sure of the preferred approach, hence the RFC. I'll take no offense corrections here.
- I changed the .inc, but didn't bump the PR of the existing recipes and didn't remove the existing 2.6 variants. If either of these should have been done, let me know and I'll respin.
- I bumped the default to be 3.1. If that's too agressive for the default, and we'd prefer 3.0.8, let me know and I'll respin.
I built and booted all the qemu machines with the 3.1 kernel headers. So from the testing I was able to do, this looks to be safe and ready to go.
This is based on my yocto repo, I also did the changes in my oe-core repository, but I don't have a oe-core contrib branch that I could push to, so I chose to send the yocto variant. If someone points me to who I email for an oe-core contrib branch, I can push that variant as well.
Cheers,
Bruce
The following changes since commit fc94f925e848684244a38dcffe15cb1192dfbed8:
Martin Jansa (1):
libxml-parser-perl, libxml-simple-perl, expat, sgmlspl-native, git: bump PR to rebuild after perl upgrade
are available in the git repository at:
git://git.pokylinux.org/poky-contrib zedd/libc-headers
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/libc-headers
Bruce Ashfield (1):
linux-libc-headers: provide 3.0.x and 3.1 headers
meta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 15 +++++- .../linux-libc-headers/linux-libc-headers_3.0.8.bb | 53 ++++++++++++++++++++ .../linux-libc-headers/linux-libc-headers_3.1.bb | 53 ++++++++++++++++++++ 4 files changed, 120 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
PATCH 1/1 linux-libc-headers: provide 3.0.x and 3.1 headers
This changes makes two different 3.x headers available to the toolchain. The latest 3.0.x and 3.1 tarballs. Compatibility is maintained with older 2.6 headers by creating a new variable that changes the SRC_URI based on the major version number of the kernel.
Tested with 2.6.37.2, 3.0.8 and 3.1 builds and boots.
--- meta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 15 +++++- .../linux-libc-headers/linux-libc-headers_3.0.8.bb | 53 ++++++++++++++++++++ .../linux-libc-headers/linux-libc-headers_3.1.bb | 53 ++++++++++++++++++++ 4 files changed, 120 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
meta/conf/distro/include/tcmode-default.inc +1 -1
@@ -21,7 +21,7 @@ SDKGCCVERSION ?= "4.6%" BINUVERSION ?= "2.21.1a" EGLIBCVERSION ?= "2.13" UCLIBCVERSION ?= "0.9.32" -LINUXLIBCVERSION ?= "2.6.37.2" +LINUXLIBCVERSION ?= "3.1" # Temporary preferred version overrides for PPC PREFERRED_VERSION_u-boot-mkimage-native_powerpc ?= "2009.08"
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +13 -2
@@ -1,9 +1,20 @@ -DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's use." +DESCRIPTION = "Sanitized set of kernel headers for the C library's use." SECTION = "devel" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" -SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v2.6/linux-${PV}.tar.bz2" + +python __anonymous () { + import bb, re, string + + major = bb.data.getVar("PV",d,1).split('.')[0] + if major == "3": + bb.data.setVar("HEADER_FETCH_VER", "3.0", d) + else: + bb.data.setVar("HEADER_FETCH_VER", "2.6", d) +} + +SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.bz2" #DEPENDS = "cross-linkage" RDEPENDS_${PN}-dev = ""
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb new file +53 -0
53 lines not on this page · raw message
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb new file +53 -0
53 lines not on this page · raw message
Signature · 1 line
1.7.0.4
Re: [PATCH 1/1] linux-libc-headers: provide 3.0.x and 3.1 headers
Quoted 9 lines · Bruce Ashfield
This changes makes two different 3.x headers available to the toolchain. The latest 3.0.x and 3.1 tarballs. Compatibility is maintained with older 2.6 headers by creating a new variable that changes the
SRC_URIbased on the major version number of the kernel.Tested with 2.6.37.2, 3.0.8 and 3.1 builds and boots.
Signed-off-by Bruce Ashfield <[email protected]>
Quoted 8 lines
--- meta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 15 +++++- .../linux-libc-headers/linux-libc-headers_3.0.8.bb | 53 ++++++++++++++++++++ .../linux-libc-headers/linux-libc-headers_3.1.bb | 53 ++++++++++++++++++++ 4 files changed, 120 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
Can someone please explain to me why we don't move some of the bits in the .bb file into the .inc rather than duplicating it each time?
Cheers,
Richard
Re: [PATCH 1/1] linux-libc-headers: provide 3.0.x and 3.1 headers
Quoted 19 lines · Richard Purdie
Quoted 9 lines · Bruce Ashfield
This changes makes two different 3.x headers available to the toolchain. The latest 3.0.x and 3.1 tarballs. Compatibility is maintained with older 2.6 headers by creating a new variable that changes the
SRC_URIbased on the major version number of the kernel.Tested with 2.6.37.2, 3.0.8 and 3.1 builds and boots.
Signed-off-by Bruce Ashfield<[email protected]>Quoted 8 lines
--- meta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 15 +++++- .../linux-libc-headers/linux-libc-headers_3.0.8.bb | 53 ++++++++++++++++++++ .../linux-libc-headers/linux-libc-headers_3.1.bb | 53 ++++++++++++++++++++ 4 files changed, 120 insertions(+), 3 deletions(-)create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
Quoted 2 lines
Can someone please explain to me why we don't move some of the bits in the .bb file into the .inc rather than duplicating it each time?
I wondered the same thing. I can refactor it if no one objects.
Bruce
Quoted 5 lines
Cheers,
Richard
Re: [PATCH 1/1] linux-libc-headers: provide 3.0.x and 3.1 headers
In reply to Bruce AshfieldQuoted 44 lines · Bruce Ashfield
This changes makes two different 3.x headers available to the toolchain. The latest 3.0.x and 3.1 tarballs. Compatibility is maintained with older 2.6 headers by creating a new variable that changes the
SRC_URIbased on the major version number of the kernel.Tested with 2.6.37.2, 3.0.8 and 3.1 builds and boots.
Signed-off-by Bruce Ashfield <[email protected]>--- meta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 15 +++++- .../linux-libc-headers/linux-libc-headers_3.0.8.bb | 53 ++++++++++++++++++++ .../linux-libc-headers/linux-libc-headers_3.1.bb | 53 ++++++++++++++++++++ 4 files changed, 120 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bbmeta/conf/distro/include/tcmode-default.inc +1
-1@@ -21,7 +21,7 @@ SDKGCCVERSION ?= "4.6%" BINUVERSION ?= "2.21.1a" EGLIBCVERSION ?= "2.13" UCLIBCVERSION ?= "0.9.32" -LINUXLIBCVERSION ?= "2.6.37.2" +LINUXLIBCVERSION ?= "3.1" # Temporary preferred version overrides for PPC PREFERRED_VERSION_u-boot-mkimage-native_powerpc ?= "2009.08"meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +2
-2@@ -1,9 +1,20 @@ -DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's use." +DESCRIPTION = "Sanitized set of kernel headers for the C library's use." SECTION = "devel" LICENSE = "GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" -SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v2.6/linux-${PV}.tar.bz2" +
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc line 16
Quoted 10 lines
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +10
-0+python __anonymous () { + import bb, re, string + + major = bb.data.getVar("PV",d,1).split('.')[0] + if major == "3": + bb.data.setVar("HEADER_FETCH_VER", "3.0", d) + else: + bb.data.setVar("HEADER_FETCH_VER", "2.6", d) +} +
Just for reference, this kind of code whilst nice, does have a reasonable amount of overhead. For something which is effectively legacy setting MAJORVERSION = "3.0" in the recipe probably isn't a big deal.
Also, please do d.getVar("PV", True) instead of the above. The "1" is bad and should be "True" and its neater to access d's getVar method directly now. I appreciate there is a lot of older code but any new code should use this approach.
There is also no need to import string (since its unused) and bb above (since its already always included).
In answer to your other question, its probably safe to drop the older versions and switch to 3.1 at this point unless there are known compatibility issues?
My other comment about moving code to the .inc also stands and I didn't intend to sound as grumpy as it does when I read it back!
Cheers,
Richard
Re: [PATCH 1/1] linux-libc-headers: provide 3.0.x and 3.1 headers
Quoted 7 lines · Richard Purdie
Quoted 5 lines · Bruce Ashfield
This changes makes two different 3.x headers available to the toolchain. The latest 3.0.x and 3.1 tarballs. Compatibility is maintained with older 2.6 headers by creating a new variable that changes the
SRC_URIbased on the major version number of the kernel.
Quoted 5 lines
Quoted 1 line
Tested with 2.6.37.2, 3.0.8 and 3.1 builds and boots.
In answer to your other question, its probably safe to drop the older versions and switch to 3.1 at this point unless there are known compatibility issues?
Don't we have 2.6-kernel left? If so, I guess that we ought to leave the 2.6 versions of the recipe. At least if I remember correctly in that a userspace compiled against a certain version of kernel headers should run OK on a newer kernel, but isn't guarenteed to run OK on an older kernel. Correct me if I'm wrong...
Cheers,
Anders
Signature · 2 lines
Anders Darander ChargeStorm AB / eStorm AB
Re: [PATCH 1/1] linux-libc-headers: provide 3.0.x and 3.1 headers
Quoted 14 lines · Anders Darander
Quoted 7 lines · Richard Purdie
Quoted 5 lines · Bruce Ashfield
This changes makes two different 3.x headers available to the toolchain. The latest 3.0.x and 3.1 tarballs. Compatibility is maintained with older 2.6 headers by creating a new variable that changes the
SRC_URIbased on the major version number of the kernel.Quoted 5 lines
Quoted 1 line
Tested with 2.6.37.2, 3.0.8 and 3.1 builds and boots.
In answer to your other question, its probably safe to drop the older versions and switch to 3.1 at this point unless there are known compatibility issues?
Quoted 5 lines
Don't we have 2.6-kernel left? If so, I guess that we ought to leave the 2.6 versions of the recipe. At least if I remember correctly in that a userspace compiled against a certain version of kernel headers should run OK on a newer kernel, but isn't guarenteed to run OK on an older kernel. Correct me if I'm wrong...
Forget my reply above, I'm obviously not looking closely enough at the patch. (Which tells me I'm getting tired and should get some rest/sleep).
Cheers,
Anders
Signature · 2 lines
Anders Darander ChargeStorm AB / eStorm AB
Re: [PATCH 1/1] linux-libc-headers: provide 3.0.x and 3.1 headers
In reply to Richard PurdieQuoted 60 lines · Richard Purdie
Quoted 44 lines · Bruce Ashfield
This changes makes two different 3.x headers available to the toolchain. The latest 3.0.x and 3.1 tarballs. Compatibility is maintained with older 2.6 headers by creating a new variable that changes the
SRC_URIbased on the major version number of the kernel.Tested with 2.6.37.2, 3.0.8 and 3.1 builds and boots.
Signed-off-by Bruce Ashfield <[email protected]>---
meta/conf/distro/include/tcmode-default.inc | 2 +- .../linux-libc-headers/linux-libc-headers.inc | 15 +++++- .../linux-libc-headers/linux-libc-headers_3.0.8.bb | 53 ++++++++++++++++++++ .../linux-libc-headers/linux-libc-headers_3.1.bb | 53 ++++++++++++++++++++4 files changed, 120 insertions(+), 3 deletions(-)create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb create mode 100644 meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
meta/conf/distro/include/tcmode-default.inc +0
-0@@ -21,7 +21,7 @@ SDKGCCVERSION ?= "4.6%"BINUVERSION ?= "2.21.1a"
EGLIBCVERSION ?= "2.13"
UCLIBCVERSION ?= "0.9.32"meta/conf/distro/include/tcmode-default.inc +1
-1-LINUXLIBCVERSION ?= "2.6.37.2" +LINUXLIBCVERSION ?= "3.1"# Temporary preferred version overrides for PPC PREFERRED_VERSION_u-boot-mkimage-native_powerpc ?= "2009.08"
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +1
-1@@ -1,9 +1,20 @@ -DESCRIPTION = "Sanitized set of 2.6 kernel headers for the C library's use." +DESCRIPTION = "Sanitized set of kernel headers for the C library's use."SECTION = "devel"
LICENSE = "GPLv2"LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +1
-1-SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/v2.6/linux-${PV}.tar.bz2" +meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc line 16
Quoted 10 lines
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc +10
-0+python __anonymous () { + import bb, re, string + + major = bb.data.getVar("PV",d,1).split('.')[0] + if major == "3": + bb.data.setVar("HEADER_FETCH_VER", "3.0", d) + else: + bb.data.setVar("HEADER_FETCH_VER", "2.6", d) +} +Just for reference, this kind of code whilst nice, does have a reasonable amount of overhead. For something which is effectively legacy setting MAJORVERSION = "3.0" in the recipe probably isn't a big deal.
Quoted 4 lines
Also, please do
d.getVar("PV", True)instead of the above. The "1" is bad and should be "True" and its neater to access d's getVar method directly now. I appreciate there is a lot of older code but any new code should use this approach.
Ack'd. I stole this from an old example, so I propagated a crime. I can fix it up and send v3. I was a bit worried about users of the .inc I couldn't see, so I think I'll keep the python code around (unless I hear a strong objection) for now, and we can slate it to be killed off entirely in the future.
Quoted 7 lines
There is also no need to import string (since its unused) and bb above (since its already always included).
In answer to your other question, its probably safe to drop the older versions and switch to 3.1 at this point unless there are known compatibility issues?
I don't know of any, everything worked here. So I'll spin a 3 part series, update, addition and removal and I'll leave it up to you about which parts you want.
Quoted 3 lines
My other comment about moving code to the .inc also stands and I didn't intend to sound as grumpy as it does when I read it back!
No worries. I didn't read it that way either!
Bruce
Quoted 11 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"