Patchwork [1/1] linux-libc-headers: provide 3.0.x and 3.1 headers

login
register
mail settings
Submitter Bruce Ashfield
Date Oct. 26, 2011, 6:25 p.m.
Message ID <0ec24ded3f71c54e544d953de65d142717f48022.1319652972.git.bruce.ashfield@windriver.com>
Download mbox | patch
Permalink /patch/13871/
State New, archived
Headers show

Comments

Bruce Ashfield - Oct. 26, 2011, 6:25 p.m.
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.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 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
Richard Purdie - Oct. 26, 2011, 8:25 p.m.
On Wed, 2011-10-26 at 14:25 -0400, Bruce Ashfield wrote:
> 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.
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  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
Bruce Ashfield - Oct. 26, 2011, 8:26 p.m.
On 11-10-26 04:25 PM, Richard Purdie wrote:
> On Wed, 2011-10-26 at 14:25 -0400, Bruce Ashfield wrote:
>> 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.
>>
>> Signed-off-by: Bruce Ashfield<bruce.ashfield@windriver.com>
>> ---
>>   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?

I wondered the same thing. I can refactor it if no one
objects.

Bruce

>
> Cheers,
>
> Richard
>
Richard Purdie - Oct. 26, 2011, 9:01 p.m.
On Wed, 2011-10-26 at 14:25 -0400, Bruce Ashfield wrote:
> 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.
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  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
> 
> diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
> index 2bf1beb..ed722be 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -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"
> 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 014024f..4e874fe 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
> @@ -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)
> +}
> +

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
Anders Darander - Oct. 26, 2011, 9:14 p.m.
* Richard Purdie <richard.purdie@linuxfoundation.org> [111026 23:02]:
> On Wed, 2011-10-26 at 14:25 -0400, Bruce Ashfield wrote:
> > 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.

> 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
Anders Darander - Oct. 26, 2011, 9:18 p.m.
* Anders Darander <anders@chargestorm.se> [111026 23:14]:
> * Richard Purdie <richard.purdie@linuxfoundation.org> [111026 23:02]:
> > On Wed, 2011-10-26 at 14:25 -0400, Bruce Ashfield wrote:
> > > 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.

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

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
Bruce Ashfield - Oct. 27, 2011, 12:53 a.m.
On Wed, Oct 26, 2011 at 5:01 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Wed, 2011-10-26 at 14:25 -0400, Bruce Ashfield wrote:
>> 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.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>  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
>>
>> diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
>> index 2bf1beb..ed722be 100644
>> --- a/meta/conf/distro/include/tcmode-default.inc
>> +++ b/meta/conf/distro/include/tcmode-default.inc
>> @@ -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"
>> 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 014024f..4e874fe 100644
>> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> @@ -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)
>> +}
>> +
>
> 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.

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.

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

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

>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Patch

diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
index 2bf1beb..ed722be 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -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"
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 014024f..4e874fe 100644
--- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
@@ -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 = ""
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb
new file mode 100644
index 0000000..3c845ef
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.0.8.bb
@@ -0,0 +1,53 @@ 
+require linux-libc-headers.inc
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "unifdef-native"
+PR = "r1"
+
+SRC_URI += " file://connector-msg-size-fix.patch"
+
+S = "${WORKDIR}/linux-${PV}"
+
+set_arch() {
+	case ${TARGET_ARCH} in
+		alpha*)   ARCH=alpha ;;
+		arm*)     ARCH=arm ;;
+		cris*)    ARCH=cris ;;
+		hppa*)    ARCH=parisc ;;
+		i*86*)    ARCH=i386 ;;
+		ia64*)    ARCH=ia64 ;;
+		mips*)    ARCH=mips ;;
+		m68k*)    ARCH=m68k ;;
+		powerpc*) ARCH=powerpc ;;
+		s390*)    ARCH=s390 ;;
+		sh*)      ARCH=sh ;;
+		sparc64*) ARCH=sparc64 ;;
+		sparc*)   ARCH=sparc ;;
+		x86_64*)  ARCH=x86_64 ;;
+		avr32*)   ARCH=avr32 ;;
+		bfin*)    ARCH=blackfin ;;
+		microblaze*) ARCH=microblaze ;;
+	esac
+}
+
+do_configure() {
+	set_arch
+	oe_runmake allnoconfig ARCH=$ARCH
+}
+
+do_compile () {
+}
+
+do_install() {
+	set_arch
+	oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
+	# Kernel should not be exporting this header
+	rm -f ${D}${exec_prefix}/include/scsi/scsi.h
+
+	# The ..install.cmd conflicts between various configure runs
+	find ${D}${includedir} -name ..install.cmd | xargs rm -f
+}
+
+BBCLASSEXTEND = "nativesdk"
+SRC_URI[md5sum] = "eac4d398a0ecd98214487cd47a228998"
+SRC_URI[sha256sum] = "4ed16da319848f681f711dbda2ac2cf1b306a280ec22f90bae190cf23b533add"
diff --git a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
new file mode 100644
index 0000000..5f9fe64
--- /dev/null
+++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_3.1.bb
@@ -0,0 +1,53 @@ 
+require linux-libc-headers.inc
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "unifdef-native"
+PR = "r1"
+
+SRC_URI += " file://connector-msg-size-fix.patch"
+
+S = "${WORKDIR}/linux-${PV}"
+
+set_arch() {
+	case ${TARGET_ARCH} in
+		alpha*)   ARCH=alpha ;;
+		arm*)     ARCH=arm ;;
+		cris*)    ARCH=cris ;;
+		hppa*)    ARCH=parisc ;;
+		i*86*)    ARCH=i386 ;;
+		ia64*)    ARCH=ia64 ;;
+		mips*)    ARCH=mips ;;
+		m68k*)    ARCH=m68k ;;
+		powerpc*) ARCH=powerpc ;;
+		s390*)    ARCH=s390 ;;
+		sh*)      ARCH=sh ;;
+		sparc64*) ARCH=sparc64 ;;
+		sparc*)   ARCH=sparc ;;
+		x86_64*)  ARCH=x86_64 ;;
+		avr32*)   ARCH=avr32 ;;
+		bfin*)    ARCH=blackfin ;;
+		microblaze*) ARCH=microblaze ;;
+	esac
+}
+
+do_configure() {
+	set_arch
+	oe_runmake allnoconfig ARCH=$ARCH
+}
+
+do_compile () {
+}
+
+do_install() {
+	set_arch
+	oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix} ARCH=$ARCH
+	# Kernel should not be exporting this header
+	rm -f ${D}${exec_prefix}/include/scsi/scsi.h
+
+	# The ..install.cmd conflicts between various configure runs
+	find ${D}${includedir} -name ..install.cmd | xargs rm -f
+}
+
+BBCLASSEXTEND = "nativesdk"
+SRC_URI[md5sum] = "8d43453f8159b2332ad410b19d86a931"
+SRC_URI[sha256sum] = "2573d2378c754b0c602b57586e9311e5b38c5d1e6c137f02873833633a4b9359"